1. Java Unit Testing
2. A Simple Unit Test
3. Assert Methods
4. Matchers
5. Testing for Exceptions
6. Stub, Mock and Proxy Testing
7. Subclass Mock Objects
8. Mock Testing isn't Always Enough
9. IO Testing
10. Servlet Unit Testing
11. Unit Testing with Dependency Injection Containers
12. Database Unit Testing - Rollback Transactions
13. Database Unit Testing - CRUD Testing
14. Database Unit Testing - Test Data Creation
15. Running Unit Tests With Ant
16. Running Unit Tests With Maven
17. Running Unit Tests Inside IntelliJ IDEA
18. Code Coverage
19. Design for Testability
20. Test First Development

• Test First Means Contract First
• Test First Forces you to Design for Testability Upfront
• The Test is a Step by Step Implementation Guide
• You Won't Forget to Test
• Test First is Hard During Experimental Programming

Test first development, also known as Test Driven Development (TDD) is a development style in which you write the unit tests before you write the code to test.

I have tried test driven development from time to time, on various minor projects, but never on larger projects with lots of people. This text here contains my own, limited experiences with TDD.

Test First Means Contract First

The advantage of test driven development is, that you force yourself to think about how the unit (the component) is going to work. In other words, you force yourself to think about the contract of its interface. Actually, the asserts in the unit test specify the contract of the unit.

Test First Forces you to Design for Testability Upfront

Sometimes, when writing a unit test after you have implemented some component, you realize that it is hard to test. You may then decide to make some design changes to the code, to make it easier to test.

During test driven development (TDD) you force yourself to think about both the contract (as mentioned above), and the testability of the component, before you start implementing it. This way you may naturally design components that are easier to test, rather than having to redesign them later.

The Test is a Step by Step Implementation Guide

Once the unit test is implemented, you can implement the unit (the component) assert by assert. In other words, you run your unit test, see which assert that fails, then implement whatever it takes to make that assert succeed, then move on to the next assert.

You Won't Forget to Test

Sometimes, when developing the test after the components, you either forget, skip, or write less good tests. For instance, if you are already a bit behind the schedule on that particular task, you might be tempted to skip the test, or just write a very basic test.

During test first development this temptation is much smaller. Especially if you do not start implementing the component until the test is 100% done.

Test First is Hard During Experimental Programming

The only time I have found it hard to do test first development is when doing experimental programming. That is, I don't really yet know how the finished design of the component will look, because I don't really know how I'll be able to implement the required functionality. Sometimes the final design doesn't emerge until after many experiments, inchorent code pieces, redesigns etc. In those situations, test first is somewhat harder to do.