File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Continuous Integration  Vs  TDD(Test Driven Development) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Continuous Integration  Vs  TDD(Test Driven Development)" Watch "Continuous Integration  Vs  TDD(Test Driven Development)" New topic
Author

Continuous Integration Vs TDD(Test Driven Development)

kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1382
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

Joined: Dec 12, 2003
Posts: 608
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


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31070
    
232

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I'll just add that Martin Fowler recently updated his infamous article on the topic.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Vladimir Manolov
Greenhorn

Joined: Jun 28, 2006
Posts: 5
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Continuous Integration Vs TDD(Test Driven Development)