Test Driven Development

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.

• Refactor without fear
• Easily maintain and extend the application
• Reduce maintenance costs
• High code quality

1. Write production code only to make a failing unit test pass.
2. Write only enough of a unit test to fail.
3. Write only enough production code to make the failing unit test pass.

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

• Add a test
• Run all tests and see if the new test fails
• Write the code
• Run tests
• Refactor code
• Repeat

The solution is not working now. If you refactor it now, you'll propably get a bigger mess because you can not determinate if the things you do do work.

The missed feature is the most interesting pitfall. You have to write as many tests as possible to be sure every test case will be covered. Even when all test pass, you will not be sure the software is tested for any case but at least you know all the current cases are covered.

Test fixture describes the setting of a test. If you want to run a test several times, you have to ensure that the software starts everytime in the same state and the prerequisites are all well known. For this purpose you have methods like setUp() and tearDown() in your testing class\tool.

Mock Objects are special case objects that mimic real objects for testing. They are objects pre-programmed with expectations which form a specification of the calls they are expected to receive

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.

Use them to have some fixture for your test. If you want to test class A and it depends on functions in class B and C you can test each of them seperatly by using stubs and mocks. So if you break the implementation of B only the tests of B will fail and you won’t have to start searching for the regression in A.

Test fixture describes the setting of a test. If you want to run a test several times, you have to ensure that the software starts everytime in the same state and the prerequisites are all well known.
You can archive this within the setUp() and tearDown() methods. The names of the methods can be different in each testing tool like JUnit, PHPUnit or other testing software.

Let the tested method to launche the exception and use a notation to let your testing suite that the current testing method will launch an exception. Each testing enviroment can be different. Read the related documentation.

Be sure to cover all cases with your test. After your test suite is OK you can go on with:

• Test coverage: run your test suite code coverage tool.
• Continuous Integration: build your entire project.