Automazione dei test funzionali passo dopo passo

Question

Automazione dei test funzionali passo dopo passo

#1 da (2 voti)

0

Ho una classe base in C # dalla quale creo classi ereditate per gli scenari di databinding. Puoi considerarlo come un sostituto della classe DataRow di .NET.

Voglio automatizzare il test della durata tipica di una riga, assicurandoti che elementi come lo stato dell'oggetto e il rilevamento delle modifiche rimangano coerenti.

Il mio primo pensiero è stato semplicemente utilizzare la classe di unit test con un metodo che avrebbe fatto più operazioni e affermazioni successive, come questa:

/*
For the sake of keeping this as simple as possible, let's just assume
that new instances can be created with a public constructor, as "unchanged".
*/

var row = new PocoTest(); // Derived from aforementionned base class

Assert.AreEqual(RecordStates.Unchanged, row.RecordState);
Assert.IsFalse(row.IsPropertyModified("MyProperty"));

row.MyProperty = "this is a new value";

Assert.AreEqual(RecordStates.Modified, row.RecordState);
Assert.IsTrue(row.IsPropertyModified("MyProperty"));

row.AcceptChanges();

Assert.AreEqual(RecordStates.Unchanged, row.RecordState);
Assert.IsFalse(row.IsPropertyModified("MyProperty"));

Tuttavia, questo non sembra corretto nel paradigma di test delle unità in cui è consigliabile avere solo una cosa alla volta sottoposta a test.

Quindi sto cercando qualche consiglio, qui. Sto pensando troppo a questo? Dovrei continuare a farlo in questo modo? O c'è un altro, migliore e più adatto modo di realizzare qualcosa di simile?

tdd testing c# .net visual-studio

posta Crono 03.07.2015 - 16:45

fonte

1 risposta

Leggi altre domande sui tag tdd testing c# .net visual-studio

Sostituire un ambiente JAVA EE aziendale con una soluzione leggera Classe con proprietà di navigazione e con o senza chiave esterna

score 2 · Answer 1

Ricorda che molte regole in programmazione sono essenzialmente raccomandazioni che puoi seguire. Quindi a volte questo è accettabile.

I test unitari vengono chiamati in questo modo perché si concentrano sulla verifica di singole unità di lavoro. In genere, se hai bisogno di più di un'asserzione per ogni caso di test, sei

strutturare il test in modo inappropriato.
testare i flussi di codice alternativi nel metodo, che si consiglia di testare con un test separato.
il tuo metodo fa troppo e dovrebbe essere suddiviso.

Vorrei suddividere il test in 3 test e nominarli in modo appropriato. La prossima volta che avrai 3000 test unitari nel tuo sistema e uno di questi fallisce durante l'automazione, non vedresti "TestRowLifeTme" fallito. Vedrai: "TestRowSetValue" fallito, che è molto più utile e specifico.