Una delle cose con cui faccio fatica quando i test unitari stanno decidendo quali comportamenti effettivamente testare. Penso che parte della mia lotta derivi dal modo in cui la maggior parte delle esercitazioni di test di unità non utilizzano buoni esempi di cose che si vorrebbe realmente testare nella vita reale. Ad esempio, il tutorial che sto guardando ora ha un test sostanzialmente simile a questo:
[Test]
public void TestQuizIsInitializedCorrectly() {
var question = QuizQuestion() {
Question = "What is your favorite color?",
Answer = "Blue, no yelloooowwww........" }
var game = new Game(new List<QuizQuestion>(new[] { question }));
Assert.AreEqual(1, game.Questions.Count);
}
Qual è il punto di questo test? Per verificare che quando si inserisce un oggetto in una lista in C #, la Lista abbia ancora solo 1 oggetto? E 'sciocco e potrei passare un milione di anni a scrivere test unitari che convalidano cose semplici come mettere un oggetto in una lista e convalidare il conteggio delle liste è 1. Non finirei mai la mia app. Questi sono solo dei brutti esempi di cosa testare in modo che possiamo concentrarci su come testare nel tutorial?
Oppure le persone scrivono davvero test come questo? Forse test come questo non stanno testando il tuo codice, ma stanno formalizzando un'ipotesi su come ci aspettiamo che le persone usino la classe Game? Forse l'esempio precedente potrebbe essere scritto non tanto per verificare che la domanda sia stata inizializzata con successo nella Lista, ma piuttosto per formalizzare l'assunto che la classe Game può essere passata solo in domande, non può aggiungere domande di default. Potrei sapere che non lo sta facendo ora, ma metterlo in un test di unità lo rende così sappiamo subito se qualche sviluppatore futuro cambia la classe Game per invalidare tale ipotesi.
Si tratta di un caso di uso comune nei test unitari? Scrivere i test non tanto per testare il codice che è stato scritto, ma per formalizzare le ipotesi per la protezione da modifiche future?