Continuous integration implies that you build your system whenever it changes. You may choose to run your test suite at that point, which is a good idea, but you're not required to.
With Test Driven Development (TDD) you combine both a test-first development (TFD) approach and refactoring. With TFD you write a test before you write enough production code to fulfill that test. With refactoring you improve the design of your code without changing its semantics.
Kri, Continuous integration and unit testing reinforce each other. Note the verbiage I use - unit testing != TDD.
You could do either of the following: 1) Continuous integration without TDD - You could write the tests after a small chunk of code. Here, you are writing unit tests before putting the code in the repository, but not before writing the code. This is not TDD. 2) Continuous integration without unit testing - This is the scenario Scott described. Extremely risky as you are hoping that the code works while asking others to pull it in. 3) Unit tests without continuous integration - Our team started writing unit tests quite some time before we started doing continuous integration. It's hard to introduce both at the same time as it is difficult to imagine the code in the repository being stable at all times before you start writing tests.
1) Write tests before you write the code (TDD) 2) puth both production code and unit tests in the repository as soon as possible. Preferably on the same day as you created them. You can still continue working on the production code and on the unit tests. 3) Make several builds per day, before each delivery to the repository. Thus you will avoid delivering wrong code (with compilation errors or with failing tests). Install the software and run acceptance tests every day (Continuous Integration). Good tool for Continuous Integration is CruiseControl: CruiseControl Homepage
Yeast devil! Back to the oven that baked you! And take this tiny ad too:
professionally read, modify and write PDF files from Java