Fundamental TDD: stuck with writing a test so I can write code that I want

Question

I have a Season class. This Season has a few properties: among them, a list of Games. This should be populated from the same source that populated the rest of the Season properties.

I have a test to ensure all items in that list are of type Game.

There is no hard requirement that a Season must contain any Games, so testing that the list is not empty would not be entirely correct -- however, the test Season I'm using has plenty of games in it.

Writing "the minimum amount of code to make a test pass" is already done, because it is the empty list (so there are no not-Game objects).

What would be the fundamental TDD way to get the production code to parse+add games to the Season object?

Would the pragmatic way be to test via the size?

---

An alternative would be to generate the list of Games in my test, and see if Season.games == list_of_games

The problem with that is that there are a crapload of Foreign relations that will be going into those games, making the test code equivilant to the method that I'm testing -- which I don't think is the way it should work.

Or should I build them "by hand" from the test data -- instead of parsing it?

Answer 1

If I understand correctly, there is a requirement that states "a Season has a list of 0 or more Game objects. This list shall not contain objects of other types".

The easiest way to verify this requirement is via the method to add items to the list. You have a test to verify that it is possible to add Game objects to the list, and you have a second test to verify that adding non-Game objects fails.

(Exception: If you use a statically-type language, like C++, C# or Java, and you use the type system to ensure only Game objects can be added to the list, the second test is effectively performed by the compiler each time you write code to add an item to the list. There is no need then to write the test yourself.)

Answer 2

Extracting data from XML or JSON always seems a bit difficult to do in a TDD manner. You end up with a lot of code that looks like:

void parseElement(XMLElement element)
{
     name = element.getAttribute("name");
     home_team = teams.lookup( element.getAttribute("home") );
     away_team = teams.lookup( element.getAttribute("away") );
}

I can add assertions to check the name and teams, but it feels rather hard to justify. The code is so simple that attempting to verify that it actually works seems not worthwhile. Sure it makes sense to run the code and make sure it doesn't go up in flames, and it makes sense to check any non-trivial actions. But it is really worthwhile asserting each and every assignment? All you are really doing is redunandtly stating the same thing.

This is what I think you are hitting. Its a lot of work to verify that the deserialization was correct, but it doesn't really seem worthwhile. That's why you're hesitant to create a list of Games to test against. That's a lot of effort for little gain.

My solution is to devise a framework for extracting information, test that, and mostly trust that it works when applied to your objects. I don't know what language you are using, but here is a pythonish version.

class Season(XMLExtractable):
    XML_FIELDS = {
         'name' : AttributeGetter('name', str),
         'games' : ChildNodeGetter('game', Game),
         ...
    }

The XML_FIELDS dict tells me where each attribute should get its data. The objects constructed here have methods to fetch the value. I've tested all those objects, and I can mostly just trust that they work here. Basically, we move all the redundancy into data and operate on that data. We can test our operations on the data, but we'll assume the data is correct.