Slashdot Mirror
Test-Driven Development by Example
What it's all about: Test-driven development is about being able to take tiny little steps forward, test that the step took you in the right direction, and repeat. The "TDD Mantra" is red/green/refactor:
- Red: write a test which will exercise a feature, but which will fail (because you haven't yet written the code)
- Green: make the test succeed, doing whatever you need to do to get to "green" as quickly as possible -- don't worry about prettiness
- Refactor: now that you have code which passes the test, eliminate all the duplication
The book then shows 2 fairly detailed examples of a development project (or snippet of a project) which progress using this style of coding. The first example deals with the creation of multi-currency capabilities for an existing project. In the space of 17 chapters, the author walks you through the creation of 6 classes (1 test class, 5 functional classes), complete with the thought-processes behind them. The code is written in java, and is trivially easy to follow, because it gets introduced in tiny little chunks; most chapters are less than 6 pages in length.
The second example is the creation of a unit testing framework in Python. It is significantly more complex and real-world than the first example, but again proceeds in very small steps, and in small chapters.
The final part of the book contains patterns for test-driven development -- practical real-world advice on how to do this stuff for real. Nearly all the "patterns" are phrased as question/answer pairs, and they range from deeply technical design patterns to advice on the best way to arrange the furniture.
What's good about the book? Kent Beck is a very good writer -- his writing is clear, he is not afraid to leave out stuff he assumes you can guess for yourself, but when he does go into detail you feel it is necessary to get the big picture, rather than mere geek bravado. Even if you don't adopt Test-Driven Development, many of the ideas are well worth considering for your day-to-day coding situations.
What could have been better? The book stresses the importance of taking 'little steps,' and sometimes you feel impatient to move to more challenging tests before properly finishing the current chapter. I was also hoping for more of a discussion on the practicalities of unit testing database-driven systems, where you frequently have to test business entities which are closely coupled to the database.
Summary If you code for a living, or manage people who do, you should read this book -- it's a quick enough read -- and consider some of the assertions it makes. If you feel you're introducing more bugs than you expected, if you feel uneasy about how close your work matches the requirements, this book gives you some powerful ideas. You can purchase Test-Driven Development by Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Once my manager came in with the buzzword eXtreme Programming. I read a couple of articles, I tried it but what a disaster. I just can't stand other people nozing around in my half completed code, the extreme attention to testing and the team-spirit you ought to have. Needless to say the experiment failed and things went back to normal :-)
/(bb|[^b]{2})/
I think we must try to get rid of wanting to design and plan every little thing in front and then find out stuff doesn't work ending up running out of time and in the end having noone willing to pay for all useless efforts.
Although many people don't believe in XP it is a way to accomplish development in such a way you do get deliverables. Maybe it does not improve speed but it does improve quality and reduce risk.
So any book which is able to explain the pro's of XP and open eyes of non-believers is good.
giel.y contains 2 shift/reduce conflicts
The reason some XP projects are successful is because they actually have testing as part of the game plan. It is *shocking* to me, having been in the industry for better than a decade and pounding code for 20 years, the state of testing in corporate america. Just atrocious.
There are many labs that don't test at all, and a vast majority test poorly. I've worked in some fortune 500 labs that didn't test at all. Scary stuff. Nothing life threatening, but all of a sudden I wasn't so convinced that the reason my account was misconfigured was because *I* gave wrong data. Simply bug riddled. Those that do test often do so manually. Forgetting for a moment that humans are likely to take short-cuts and not bother to execute tests they perceive to be out of the scope of their recent change, they are failable. Of course they are, that's how the bugs got there in the first place.
So, the XP folks have the testing thing down. They test before the code is written, and their tests are automated.
Then they take leave of their senses. The claim that because they've successfully turned one idea on it's head (i.e. testing *first*) that they can turn others is ludicrous. Design first is still valuable guys. I've eliminated thousands of bugs simply by having the right design to begin with. Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser. If it weren't Scott Adams wouldn't be a millionare.
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
poliglut.org: they're still alive and fighting the man
it would be nice to have 2 developers for every problem... but that is never going to happen.
Isn't that the whole crux of XP? If you're not organized, nothing will help. If things are organized, but need tweaking, then XP can be beneficial. Having the pre-requisite of having some organization to how software is developed is the hardest part. If your PM isn't organized and you're not organized, forget about it. If you're organized, then you're probably already doing unit testing in some form.
The idea of breaking your program into small parts and testing them is fine. Writing programs to test these parts seems to be a bit problematic. I wrote a test program to test this module. But then I remembered that I forgot to write a program to test the test module! You use your specifications to write your module, then you test against these specifications. If you write a program to test these specification, then you already must have a firm grasp of the specifications. What assumptions about your module are you making when you write your test? Or is this a simple black box type test where you do not care how it works inside? Any faults that you have in your conception of your test program will be carried over into your module, or worse your module might be correct but your test program flawed. Seems like an extra layer of complexity rather than a useful method. I also dislike the do it dirty and fast, then refactor part. Proper planning and implementation seems the better approach to me. I understand that "mad hacker" instinct to dive in and code away, but that has to be restrained a bit when the complexity of the problem rises.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
but the point is you also add a "test suite" - in addition to your routine and the code that uses your routine. That way you have an "objective" test of your routine, regardless of what your app does.
Imagine if you call the same method/function from three different places - in one place it expects a return value (int) > 0, in another it expects a return value >= 0 and the third it expects any return value. Which one is right? Well, in XP your routine would be called from a fourth place - from within the test. And the version called from the test is, by XP's definition, the correct version. The test effectively becomes a specification.
eXtreme Medicine.
Your feeling I'll, so you pop along to the doctor.
Hey Doc, I have a problem can you fix it.
The Doc has an Idea what's wrong, could be complicated, but:
throws a load of drugs at you
does a some tests, your a bit better but, well have some nasty side affects.
Changes some of the drugs, and gives you a few more......
In the end, your sort of all right, but a drug addict, and occasionally have to go back and get a different fix from the Doc.
Not-so eXtreme Medicine.
Your feeling I'll, so you pop along to the doctor.
'Hey Doc, I have a problem can you fix it.'
The Doc has an Idea what's wrong, could be complicated.
I'll put you on some light medication and get an appointment with a consultant.
The consultant comes along, has a word, still not sure, advises the Doc on some better medication gets in a specialist for one of you conditions.
The doc treats most of you conditions, and some have already cleared up.
The specialist takes a look at you and give the Doc some more advise and training.
After a few months you in perfect health.
thank God the internet isn't a human right.
It sounds to me like this is just another way of designing, but that makes the wrong emphasis. These tests sound a lot like low level use-cases. You should be creating those anyways. But you should create all of those first! Not one at a time as you code.
I work in a game studio where our last project had 6 months of pre-production time. We generated reams of technical design documents. The intention was good, but they were never maintained or even referenced after their initial creation. We just said "documentation is necessary" and it needed to be done. In production, the team wasn't on the same page. Every programmer had a task list they just milled through. The assumption was the initial requirements won't change. The result was ugly. The product was subpar and a couple months late. Everyone was miserable. It sucked.
I'm currently leading a new project here. We're 6 months into production and every milestone has been delivered ON TIME and accepted by our customer. The team is focussed on the current milestone, there isn't a lot of process to get in the way. The best part is, writing code is fun again. We don't have goals we can't accomplish. And we fully expect the product requirements to change during production.
I could get into specifics about our process. But I don't think it would be that helpful. I think specific methodologies like XP are guidelines to get you started. From there, you really should re-evaluate your process frequently (a fundamental excercise to be "Agile") and make changes as necessary. Kind of like optimizing your code.
The following links gave me all the information I needed to devise an initial process plan (which included TDD). But once it was put into practice, it naturally evolved into the process we have now (which doesn't include TDD)...
The New Methodology by Martin Fowler
The Agile Manifesto
Agile Software Development Ecosystems by Jim Highsmith
I also suggest reading the chapters on "thematic milestones" in Writing Solid Code.
Requirements are the Achilles heel of XP. Without rock solid requirements, you are just guessing for the test scripts.
Take a trivial example -- an entry form for a phone number. What is a valid phone number? Add in real world things like extensions, folks using alphanumeric substitution (1-800-DISCOVER), and internationalization and it gets interesting. Now a test driver is not that big of a deal if you know what to put in it. From a design standpoint, it would really be nice to have solid requirements and test scripts that provide concrete examples as to what the business was asking for. Real world? I could only dream for mediocre requirements that might resemble not only what they asked for, but what they want.... At least enough to try and read their minds.
+++ UGUCAUCGUAUUUCU
I've done a little test-driven development on my own.
Test-driven development seems to call for a series of baby steps, each corresponding to a unit test case. Unfortunately, I wasn't always able to identify "the next baby step"; even if I could pick what I thought was the next unit test, I sometimes found myself spending far too much time, and writing far too much code, for just that next test.
I also sometimes found that "the next test case" already passed. I don't know if I wrote more than I needed to early on, or I picked the wrong next case, or if there's more to all this than I've picked up.
When I was in good TDD mode, I was flying; test, red, code, green, refactor, green, next! It's a very rapid, and very intense, experience. There's a reason XP usually calls for a 40 hour week; by the time you're done with a few hours of this, you are tired! (But you've gotten a lot done.)
Stupid job ads, weird spam, occasional insight at
Now that XP has been "out there" for a while,
does anybody have some war stories?
It's interesting. The "war" has been with management. We showed our Project Manager a couple of the books (he actually READ them) and we were allowed to use XP. After our first project was successful, we have been trying to get official approval to develop using the methodology and it has been tough.
Does the reliance on incremental development and
refactoring rather than a intricate, up-front
design really work, or result in a big wad of
band-aids?
As with any approach the team must be disciplined to
1. Test First
2. Talk to each other
3. Ask for help when needed
4. Refactor mercilessly
5. Code the simplest thing that will work
You will probably say "of course!" to all of the above, but if you don't stay disciplined within the team, you will get into trouble.
Is pair programming OK, or do you sometimes get
stuck with the nitpicker from hell who has to
have every detail his own way?
Pairing is great. If your goal is not well written simple software, you are not part of the team. You are the cowboy who is the reason the team is all working on Saturday to fix the sh*t you went off and wrote by yourself! (Ok, Ok, breathe....)
Is close involvement with the customer good, or
does it just give them daily opportunities for
endless bright ideas that prevent convergence?
The customer wants an application as quickly as possible. They have a business need and don't want to have to wait 4 more months for their great ideas to be implemented. If they continue to think off the top of their heads, they probably didn't know what they wanted in the first place and it will take that extra 4 months to get it out of them and get it into the application anyway.
XP works. Our teams are 4 or 6 programmers with a tester. When we test first and give the tester something to test that is not fragile, we get much farther much faster than "code it and throw it" at the tester and hope it works.
I worked at a company that decided to do exclusively Extreme Programming. They even hired an extreme programming coach whose name I won't mention but would be recognizable to some people. We had tons of problems as I see it but the manager likes this way of doing things so they are doing it until their VC funding runs out. I found XP to have quite a few problems.
1) Lack of planning
We didn't plan and ended up redoing things over and over. There were things we (the experienced people) knew well ahead of when we had to do them. Things that were self evident from day one and other things that a half decent architect would have recognize as needing to be addressed right away. Hoping to refactor things all the time is nuts since it ends up chewing up tons and tons of time. Writing what was suppose to be a "server" without taking into account multi-threading and more than one user was an example of this.
2) Lack of code ownership
You can?t ?fix? something when you don?t own it. The funniest example was our battle with the coach. He changed something that was working fine. We found lots of bugs in it that were a result of refactoring. We decided to change it back to a previous version but included a comment in the cvs log saying why. He must have gotten pissed and checked it all back in including the bug. Idiotic. People make mistakes and never correct themselves because there?s no feedback since they don?t live with their mistakes. Other people ?fix? it. Sometimes it?s not broken but simply a different solution to the problem. This is best called battle of the microarchitectures. The code doesn't get finished.
3) Pair programming
This was so tiring. Watching someone make mistakes and correcting them is boring. It?s worse almost for the person making the mistakes because they get constantly corrected even when they are in the middle of formulating stuff and just moving things around. It?s very tiring. You cannot force anyone to make a change because if they disagree they just keep doing what they want if they have the keyboard. How long can you complain before you get tired. If someone lives with their mistakes and corrects them fine but why have someone look it over. I didn?t see the quality of the code being any better than before we did do this stuff. In fact it tended to get worse because we were so bored we started making more and more stupid mistakes.
I'm not necessarily discouraging XP. It's great. You can actually slack off much more than in a regular shop. There's always your pair to blame and since no one owns anything there's no one to pin something on. The coach even admitted when interviewing someone that XP doesn't lead to producing experts since the knowledge is distributed in the group and no one concentrates on any particular thing.
The tests are a total joke. Since people want to test every method we have very little private methods (read encapsulation) because you can't test a private method from another class. Since it's expensive to do the set up for a method and we are testing a thousand or more methods a lot of methods are simply public static (we are doing Java BTW). Since everything is tested you just end up throwing away tons of tests every time you realize there's an easier way to do things. Some times you say to hell with refactoring something since that would mean changing tons of tests.
I totally hate working at this company. It sucks big time. Our code looks like spaghetti. I've already decided as I look for a new job that I will not work for an XP shop again. I'll consider another agile shop with an architect and some thought out plans for an architecture and testing.
The team should create a common guidelines specification which then must be agreed by everyone in the project. After that nitpicking to make stuff conform to the guideline is a good practise, since sticking to the agreed style is an improvement.
--