• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Continuous Integration Vs TDD(Test Driven Development)

 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll just add that Martin Fowler recently updated his infamous article on the topic.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic