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.

Bookmark/Search this post with:

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

Permalink

pbielicki's blog
38452 reads

Comments

Great Screencast

September 18, 2008 by Patrick Baumgartner (not verified), 1 year 49 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 49 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 49 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 49 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 49 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 49 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 49 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 49 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 49 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 47 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 47 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.