Introducing Test Driven Development in PHP

Question

My workplace consists of a lot of cowboy coders. Many of them are junior. Which coincidentally contributes to a lot of code quality issues.

I'm looking for suggestions on how to best wane my team into using TDD (we can start with Unit tests, and move into regression tests, and later more automated testing).

Ultimately, I want us to learn more quickly from our mistakes, and produce better code and breed better developers.

I'm hoping there are some practical suggestions for how to introduce TDD to a team. Specifically, what tools are best to choose in the LAMP (php) stack.

Sorry if this question is too open-ended.

Answer 1

As for the team question as well as universal ideas about software development and testing, I would suggest Joel Spolski's website and books: http://joelonsoftware.com/ I got many insights from him.

Answer 2

SimpleTest - excellent documentation and explanations of testing for php

Answer 3

Another way to start TDD is try to use PHP framework. Without framework, it's hard to implement unit test effectively.

Answer 4

Make writing tests easy and the results visible.

• Use a TestFramework with good documentation. like SimpleTest
• If test depend on database contents, create a reference database that will be dropped and created at the beginning of a script.
• Make a script that runs all test and shows the results on a standalone monitor or something that will make the test visible / easily accessable. (Running a command prompt is not an option)

I personally don't write test for every chunk of code in the application.
Focus on the domain objects in the application. In my case these are "price-calculation" and "inventory-changes"

Remind them that they are probably already writing tests, but that they delete their work just after creation. Example: During the development of a function you'll have a page/testscript in with an echo or *var_dump*() the result. After a manual validation of the result you'll modify the parameters of the function and check again.

With some extra effort these tests could be automated in a UnitTest. And which programmer doesn't like to automate stuff?

Answer 5

After going through this process four times now, I've found that any introduction of TDD will fail without some level of enforcement. Programmers do not want to switch style and will not write their first unit test and suddenly see the light.

You can enforce on a management level, but this is time-consuming for all involved. Some level of this is necessary at the beginning anyway, but ultimately you will need automatic enforcement. The answer to this is to introduce Continuous Integration.

I've found that a CI Server is the ultimate keystone to any TDD environment. Unless developers know that something bad will happen if they don't write the tests, you'll always have cowboys who feel it's beneath them.