Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Continuous Integration Vs TDD(Test Driven Development)

 
kri shan
Ranch Hand
Posts: 1478
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the difference between Continuous Integration and TDD(Test Driven Development) ? In both the cases code is tested against the Test Cases.
 
Scott Ambler
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

BTW, TDD isn't just for application code any more. You can regression test your database schema and refactor your database schema.

- Scott
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34973
379
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll just add that Martin Fowler recently updated his infamous article on the topic.
 
Vladimir Manolov
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A safe scenario would be:

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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic