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
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 ?
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 :)
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).
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?
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.
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.
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...
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.
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.
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 oftestReturnManyEntries). "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