TDD: Where should I start?

Question

I've read a lot about TDD and I've tried to develop using TDD without success ... I always stop staring at the screen...

I've learned that I should not write tests for methods or class. I should write tests for behaviors. That's because objects interact with each other and this interaction should be tested.

Following the example bellow:

Imagine that, I, as a company owner, would like to save my customers information to consult that later.

That's my business value.

Just to learn, I would not like to use any framework or library, just plain PHP and PHPUnit.

Ok, now, where should I start?

I think that my users must enter an url to go to the form ... So should I test if it's loading the page? Is this a good start? If it's true, how could I test it?

Answer 1

It sounds like you're mixing up BDD (behaviour driven development) with TDD (which isn't surprising as they're arguably very similar).

BDD is a bigger process than just the tests, but to focus on what's relevant to your question:

1. pick out an important feature that you want to implement.
2. pick a specific scenario which you feel is a representative example of the feature (personally I'd go for the simplest happy path rather than diving at exceptions or edge cases).
3. write a test at the level of abstraction that's closest to the scenario/specification. work your way outside in through each layer of abstraction until the scenario is fully implemented.
4. if you haven't covered the feature go to 2 and repeat until you have all scenarios relevant to the feature implemented
5. otherwise go to 1 and repeat until done

I think that this approach is best suited to when you're implementing something very 'businessy', on the rare occasions that I have to do something moderately complex at a low level (e.g. something with a more algorithmic or technical bent) then it becomes less useful doing vertical spikes and it's easier to stay in the same layer of abstraction and work with a more formal approach to edge cases, pre&post conditions, etc.

Edit: oh, and yes if you're doing outside in checking that the form (or more correctly enough of the form to implement your scenario) appears correctly is a good start - don't put too much emphasis on testing the GUI though, you can easily get bogged down in fragile tests.

Answer 2

I often find it easiest to start with tests for error handling. In your case this could be: if there is no client in database with given ID, raise an Exception.

Answer 3

I've learned that I should not write tests for methods or class. I should write tests for behaviors.

This is not true. Your methods should express your behaviors, and you should unit / integration test those methods and classes.

You said you use PHP, well, PHP sites usually don't have complex business logic. (disclaimer: I've said usually) The most complex part is the UI, so what you can do is first switch to doing MVC, and then you will see where your tests fit. When you have explicit methods on your controller, you can easily extract some behavior in a test which has some value.

Answer 4

save my customers information to consult that later.

Then I think a good test would be to see if you have a file on your harddrive, or an entry into a database, that contains all the "customers information". Or you simulate a user coming to your site, doing whatever, and seeing if the information was saved successfully.

What information? Yeah... that's a good question.

Answer 5

Your example is little broad. Target a small section of the problem to start with.

There are any number of places to start. You can start with the page load for the form. (Selenium is a nice tool that integrates with PHPUnit http://seleniumhq.org/projects/ide/) Or the processing of the information on the backend. You are going to have some sort of function/method that is going to process the data. What is this method going to do? Write the information to a database? Return it formatted in a specific manner? What about invalid data?

You should have a story or process in mind. For example, John Smith fills out a form with his name and address. So you can start with a test ensuring that a page comes up with a name and address field. Proceed to the next step, John Smith submits the form and the data stored in a database. So you write a test that makes sure submitted data is entered into your database. Repeat.

TDD helps serve two purposes in my mind, the first being confirmation that the code that I am writing behaves as I want it to and can be modified without causing new bugs. And second as a guide for what the code needs to do. If you provide me with your tests, I should be able to come up with a similar solution to the problem as you (the only difference being our individual coding styles).