One of the things I struggle with when unit testing is deciding what behaviors to actually test. I think part of my struggle stems from how most unit testing tutorials don't use good examples of things you would actually want to test in real life. For example, the tutorial I'm looking at now has a test basically like this:
[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);
}
What is the point of this test? To validate that when you put one object into a List in C#, that the List still has only 1 object? That's silly and I could spend a million years writing unit tests that validate simple things like putting an object into a list and validating the list count is 1. I would never finish my app. Are these just bad examples of what to test so we can focus on how to test in the tutorial?
Or do people really write tests like this? Maybe tests like this are not really testing your own code, but they are formalizing an assumption about how we expect people to use the Game class? Perhaps the above example might be written not so much to test that the question was successfully initialized into the List, but rather to formalizing an assumption that that the Game class can only be passed in questions, it can't add default questions itself. I might know it's not doing that now, but putting it in a unit test makes it so we know right away if some future developer changes the Game class to invalidate that assumption.
Is this a common use case in unit testing? Writing tests not so much to test code that's written but to formalize assumptions to protect against future changes?
