Question

I’m really confused here. Let’s say my user story looks like this.

“A user must be able to look at the stats of every player in the league so that he can scout
properly.”

Maybe the user story is bad but still how am I supposed to TDD that? I’m I supposed to test against the property I am expecting? I am really lost here and would appreciate your point of view.

EDIT: I am fairly new to TDD but I get the basic and have done a few katas

Answer 1

What you’re describing isn’t really fine-grained enough to TDD in code, but you can break it down.

First of all, how are they going to be presented with the information they need to do the search? Are they going to see all the stats? Search for a player? Search for a particular stat? This gives you finer-grained behavior, and now you can start thinking about the interface that the user will use. Think of just one example of something the user does – maybe searching for a player, perhaps visiting the first page, etc. Make it something interesting but simple.

Once you know what this part of the UI will look like, you can code it. (You could TDD it but normally the interface changes quite a bit and UI automation is hard, so most people don’t TDD UIs).

The UI will want to get some information from somewhere, and pass some information back. You’ll find yourself thinking about a collaborating class – probably a controller or a presenter – which will help the UI. In turn, that controller will want to control the interactions between some other classes – the UI itself, the repository for player stats, security, validation, etc. This is the first class you’ll write tests for.

You can now start writing the test for the controller. You already know how the UI is going to use it. Just write an example of how another class might be able to use the controller in the same way, what kind of information the controller needs, and what outcome you get when you use it.

Of course, you don’t have any other classes yet, and the controller might need them. Use interfaces for the roles that those classes will play, dependency-inject them, and mock or stub them out in your test.

At some point the controller will be ready to do something, but you still can’t run the application because you haven’t finished coding the collaborating classes – they’re still just interfaces. Do the same thing again for them – pretend you’re the controller, using them, and if they need any other classes, mock or stub them out.

Eventually you won’t have any classes to mock or stub, and the first scenario in the user interface will run. If you want to get faster feedback, at any point you can just hard-code some data so that the UI runs and you can see what it looks like.

Doing it this way is called outside-in, and is related to BDD, a slightly different way of thinking about TDD. I hope that this page might help you.