Skip to content

Video tutorial: Test Driven Development in practice

September 18, 2008 by Przemysław Bielicki

In this nine minute tutorial I'm presenting TDD way of developing software i.e. start from writing the test.

Many people often say that you should start from implementing at least interface and then start testing. In this tutorial I'm showing how easy it is to start writing unit test with nothing (not even an interface) i.e. only having the requirements. After couple of minutes I've got an interface, a working implementation and a full test suite.

This is what Test Driven Development is all about - software should be developed this way IMO. Sources for this tutorial can be found here
The voice volume is quite low so I recommend using headphones and increasing sound volume a bit while watching this video


I hope you like it. If you have any comments, please share your opinions here.

About the Author: Przemysław graduated from Gdańsk University of Technology in 2004 having specialized in Distributed Information Systems. He worked in Lufthansa Systems, Intel Corporation in the past where he developed complex IT solutions in many Java-related technologies. In professional life he is a real Java expert holding couple of Sun Java certificates (Programmer, Developer, Web Developer) and Certified Scrum Master, of course.

Przemysław is a regular contributor to AgileSoftwareDevelopment.com and the author of "From Java to Java EE" blog. He now works as a Software Craftsman in an international company that is the leading Global Distribution System (GDS) and the biggest processor of travel bookings in the world. Contact Przemysław

Comments

Great Screencast

September 18, 2008 by Patrick Baumgartner (not verified), 1 year 20 weeks ago
Comment id: 1853

Hi,

great Screencast! You show in a simple way how to do TDD without any big theories.
Is it nessecary to name the test method "testSomething"? In my opinion, you annotate the test method which should be enough, or do you think it's just for a better unsterstanding to use the same name as we used in JUnit 3.x ?

Greez

No, it is not necessary to

September 18, 2008 by pbielicki, 1 year 20 weeks ago
Comment id: 1854

No, it is not necessary to name the test method "testSomething" - it is just my old habit from JUnit 3.x. I think it's for better understanding and distinguishing the real test methods in JUnit classes.

As far as I know @Test intent was to get rid of "testSomething" convention but I'm still sticking to it. Why? Give me more meaningful method name for testing Add operation - if you find any I will use it :)

Cheers!

Refactoring after the green bar

September 18, 2008 by Artem, 1 year 20 weeks ago
Comment id: 1855

Very illustrative screencast indeed. I would like to note one thing, though. starting at the 8 min point, you extract a method from already working function (i.e. refactor), while been in the red state.

In TDD all the refactoring is supposed to happen during the green state only. In this small example and due to the intelligent ExtractMethod wizard it didn't matter much, but in real projects when I was still learning TDD several times I was able to mess up the code, when I was trying to refactor during the creation of new stuff. I find that the habit of separating the TDD phases clearly usually pays off. Especially if you are working in a less automated environment, than a typical Java programmer (my TDD background is from embedded C++ mainly).

My 2 cents

September 18, 2008 by hmoeller, 1 year 20 weeks ago
Comment id: 1856

I liked watching your video as well. Especially the heavy use of IDE convenience functionality made the process transparent and fluent.

As to the naming convention: Somebody lately suggested to name them "should". Those names can become pretty long, but they are something like a short documentation on what is under test. You won't use those names elseware anyway.

@Artem

You're right concerning the refactoring steps. But consider all those other convenience functions used. You expect them to do the right thing. When using such a sophisticated IDE, the borders between refactoring as a process step and using "enhanced editor functions" is fuzzy, isn't it?

"Should" would actually fit

September 18, 2008 by pbielicki, 1 year 20 weeks ago
Comment id: 1857

"Should" would actually fit my naming convention (maybe even better) e.g. shouldAddAndThrowOverflowException, shouldReturnManyEntries, etc. (instead of testReturnManyEntries). "Should" makes it more human-language which makes it easier to understand and tests are supposed to be the design of your system - that works perfectly.

Cool! Thanks for your comment.

On the other hand, if You

September 18, 2008 by krzysieq (not verified), 1 year 20 weeks ago
Comment id: 1858

On the other hand, if You name a method "shouldAdd", then it implies to someone new to Your code, that it's this particular method that should actually Add (kind-of wishful thinking approach), while in fact it merely tests the functionality of another method defined elsewhere. IMHO, testAdd will ever remain the most straightforward way of naming test methods. After all, everyone who has completed at least a couple of first classes of primary school knows, what a test is.

Cheers,
Chris

TestAdd method

September 18, 2008 by Sim (not verified), 1 year 20 weeks ago
Comment id: 1859

Should the test methods only test one case to have smaller test methods vs test all cases in one method?

example:
TestAddUnderflow(){
// test add underflow
}

TestAddOverflow(){
// test the add overflow
}

TestAdd{
// Test normal implementation
}

Sim

Re: TestAdd method

September 18, 2008 by pbielicki, 1 year 20 weeks ago
Comment id: 1860

It is a good practice to do this like you described (video doesn't show this due to length constraints). You can create as many test cases as you can imagine in one method and then refactor the unit test class. Remember that test classes are first-class citizens so they should also be refactored, nicely coded, blah blah blah...

I just attached source code

September 18, 2008 by pbielicki, 1 year 20 weeks ago
Comment id: 1861

I just attached source code (+ Eclipse projects files) here: http://agilesoftwaredevelopment.com/files/tdd-tutorial.zip

Detour

October 3, 2008 by me (not verified), 1 year 18 weeks ago
Comment id: 1890

If you are only testing requirements you were given, you are going to miss something. I see no real benefit in TDD as you are just taking longer to arrive at the same point. You still have to add test cases to test the code that you wrote that doesn’t necessarily test the given requirement.

TDD is just another way to do things, nothing more.

No, you are not testing only

October 3, 2008 by pbielicki, 1 year 18 weeks ago
Comment id: 1891

No, you are not testing only given requirements. While testing and implementing your code you discover many things like exceptions, extreme values, etc. Doing this according to TDD you save your time because you end up with full test and implementation at once - it's transparent for you. And even if you miss something that's OK!!! You can add as many tests as you want later - remember that tests are to prevent bugs not to discover them.

Thanks for you comment.

Awesome

January 7, 2009 by Farhan Thawar (not verified), 1 year 4 weeks ago
Comment id: 2153

Thank you thank you thank you for this.... just sent this to my team :)

brillliant

February 19, 2009 by Anonymous (not verified), 50 weeks 4 days ago
Comment id: 2258

Very clearly put - just what I needed to crsytalise my understanding of TDD. Love how you use eclipse to generate the code as you go along!!!

HotKeys

May 6, 2009 by Ryan (not verified), 39 weeks 6 days ago
Comment id: 2518

Great video... what are the hotkeys you are using to pull up the create class... create method menus?

Re: HotKeys

May 6, 2009 by pbielicki, 39 weeks 6 days ago
Comment id: 2519

Ctrl + 1 - quick fix
Ctrl + T - find all implementation of given interface (shows type hierarchy)

I hope that helps :)

Ctrl + 1 was what I was

May 7, 2009 by Ryan (not verified), 39 weeks 5 days ago
Comment id: 2523

Ctrl + 1 was what I was looking for! Makes TDD 10x easier... in .Net/Respharper use Alt - Enter. Thanks!

evden eve nakliyat

May 25, 2009 by evden eve nakliyat (not verified), 37 weeks 23 hours ago
Comment id: 2611

thanks. wery good. evden eve nakliyat

evden eve nakliyat

May 25, 2009 by evden eve nakliyat (not verified), 37 weeks 23 hours ago
Comment id: 2612

thanks. wery good. evden eve nakliyat

Great

June 4, 2009 by Tariq (not verified), 35 weeks 5 days ago
Comment id: 2661

Great intro to TDD, and IDE features :)

Thanks!

Tariq

Great overview

June 25, 2009 by Chris (not verified), 32 weeks 4 days ago
Comment id: 2771

Watching the video is a whole lot easier to understand this concept than just reading a description. Thanks!

Thank you . Have you written

December 15, 2009 by yakub (not verified), 7 weeks 6 days ago
Comment id: 4407

Thank you . Have you written any book on TDD ??????

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com