- Java Unit Testing
- A Simple Unit Test
- Assert Methods
- Testing for Exceptions
- Stub, Mock and Proxy Testing
- Subclass Mock Objects
- Mock Testing isn't Always Enough
- IO Testing
- Servlet Unit Testing
- Unit Testing with Dependency Injection Containers
- Database Unit Testing - Rollback Transactions
- Database Unit Testing - CRUD Testing
- Database Unit Testing - Test Data Creation
- Running Unit Tests With Ant
- Running Unit Tests With Maven
- Running Unit Tests Inside IntelliJ IDEA
- Code Coverage
- Design for Testability
- Test First Development
Test First Development
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.