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.
Although it sucks to lose 20% of your code when you drive it off the lot.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
hopefully, this will last as long and have as big an impact as extreme programming did.
for the sarcasm impaired : this is sarcasm.
... hi bingo
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.
...been doing this for years anyway? My code development cycle has always been... 1. Write code to use function/procedure. 2. Write function/procedure. 3. If function/procedure==fucked return to 2 and unfuck. 4. Once it works, tidy it up. Now it appears someone else has added steps 5 and 6... 5. Write a book about it. 6. Profit!!!
What would Dilbert do?
Here and here!
I love buzzwords with X anyway..."There is no teacher but the enemy."-Mazer Rackham
You can get Martin Fowler's "Patterns of Enterprise Application Architecture" in a bundle bargain at Amazon along with Kent Beck's "Test Driven Development" for $79.98 [link to PEAA bundle]
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
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?
Is pair programming OK, or do you sometimes get stuck with the nitpicker from hell who has to have every detail his own way?
Is close involvement with the customer good, or does it just give them daily opportunities for endless bright ideas that prevent convergence?
Just wondering...
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
The RIAA issued a press release saying that they are initiating a lawsuit against Kent Beck because eXtreme Programming principles could lead to faster development of file-sharing software. The RIAA's main argument is that CD sales are falling at levels that could only be explained by eXtreme Programming.
That's why I've moved on to XXP, which focuses first on correctness of tests. First, I write a test that tests a test. Then I write the test. I test the test until the test tests ok. Then I write a test for another test, and so on.
My pair programming partner is currently working on an idea he calls "XXXP". I'll post our results if we ever finish a project without getting lost in infinite recursion.
I'd be the first to admit that XP offers a lot of risk-reduction -- for teams that are working on things that are easy to unit-test.
With a class that is supposed to take in a bond and output the yield curve, it's easy to write a unit test. But what about the next class, that renders the yield curve on the screen? What about the complex, distributed system of Excel objects and forms things that draw a network and things that flash green and go 'ping' to indicate a change, that are equally necessary but generally much harder to write and much more likely to go wrong?
Has anyone tried to apply test-first programming to complex guis? I can't say that any obvious way to do it has ever occurred to me. Worse yet, when I ask I generally find that people either
a) Are in the same position as me, or
b) Believe that a GUI is a little thing you spend a couple of days on after you finish the application
So, for now XP is something I read about rather than something I actually do.
Whence? Hence. Whither? Thither.
Last I heard, the Chrysler Compensation System was not finished, scrapped prior to going into production. What are the more recent projects that demonstrate how well XP works?
XP has worked in some small scale applications pretty well. It isn't for every project or every person, but in some cases it can be very effective, and in others (as you stated) it can be a disaster.
I think it's great that there are new ideas for ways to develop software, (although XP is actually fairly 'old' in computer science terms). There is no magic formula for producing quality software in a reasonable amount of time yet, but XP is another step in the right direction.
Note: While XP's entire methodology wasn't written down until about 1996, many of the ideas that it uses had been in circulation since the 70s.
What?
What? Is he going to write a book for every rule of XP?
Testing is important, but XP testing philosophy is a catch all for actually thinking about your product and the purpose of you product. XP is about making hack programmers look legit. XP has some good points, such as an emphasis on simplicity, testing, and customer satisfaction, but mostly it's about making bad habits look good, like no design and iterative feature hacking with ignorance to the bigger picture of the app.
Some design up front is important. Documentation is important. Code ownership is important to an extent. In a medium to large system, having everyone able to change any line of code is just stupid. People change shit and don't have a clue why the code looks the way it does. One of the arguments for no code ownership is that a lead architect can't keep it all in his head. Well, what about a team of that consist of many folks that aren't as capable as that lead architect? they are able to comprehend the whole system according to XP. And, they are allowed to change whatever they want, when they want. So, get a couple of average programmers with large egos, and you have a lot of problems.
XP is great for people who are happy doing bug fixes all day instead of avoiding the bugs to begin with. The assertion that XP results in less bugs is pure speculation and from my experience, a very misleading claim. Just because your test succeeds doesn't mean that your program is correct. And if the test is the only glue validating the success of your final solution, you're screwed.
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 once worked at a start-up where someone started on Monday, and never came back after Wednesday night, leaving a voice mail message that said, "You never told me I was going to have to work with other people!"
You're going to have to work with other people. The better you work with them, the better you work, the better everyone works. (Hugs not required.)
Stupid job ads, weird spam, occasional insight at
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
here, [pdf,yahoo.com] with more information here[vt.edu].
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
IMHO you mix things up, sorry.
eXtreme Medicine -> not so eXtreme Programming:
(in general use a lot of blahblah and don't show what you're doing)
make a big picture of all what's wrong
try to fix everything at once (dripping nose, broken legs, breast enlargements, etc)
determine whether or not thing have gone well is the patients problem (hey my?? oh, cute, well let's make em even bigger)
leave your patient, with a lot of (new) problems
not so eXtreme Medicine -> eXtreme Programming:
(in general use a little blahblah and show what you're doing)
focus on the most important issues (broken legs)
make sure you can see if it's fixed
fix the most important issue, and continue with the next important thing (dripping nose)
disencourage breat enlargement
Yes, it means that you need very good developers for XP. These people must be able to do good designing to have the big picture in mind and they must be able to judge quality.
Do they exist? Yes...
Many? Enough, but there is an awfull lot of very crappy developers out there.
giel.y contains 2 shift/reduce conflicts
I couldn't agree more.
I can't think of many jobs - at least for college/university educated people - that do not require soft skills like ability to work with your coworkers and communication (meetings, presentations, acting as a tour guide for VIPs, etc.).
I used to hate having to deal with other people any any way. In fact, that was one of the reasons why I decided to embark on a research scientists (Physics) career. As a scientist I wouldn't have to deal with people, give talks, socialize or - most imporant of all - end up in any kind of a manager/boss line of work. I would just sit, think and write papers. That's what I thought and boy how wrong I was.
Most science, and experimental physics in particular, is done in groups. There's no way around it. You can't run a lab alone so you need to have people around you. Even as a postdoc you have to be able to hire good PhD candidates and supervise them. You have to be able to interview them, understand what makes each of them tick at workplace and how to manage them to get the best out of them.
Then, unless your lab is established and extremely well funded, staffed and equipped, you often need collaboration from other groups. Making contacts with other scientists and establishing mutually beneficial collaboration requires publicity (talks!), diplomacy (socializing!) and patience.
A person who cannot work with other people simply does not fit into this environment. No matter how brilliant scientist he is, without the social skills he is very likely to turn out as nothing.
I still get slightly nervous when I have to a give a talk. I still don't like meetings. However, I have grown fond of managing people, because, as difficult as it sometimes can be, it's a wonderful feeling to see your highly motivated and skilled people working with you in harmony. The older I get the more I appreciate social skills over raw intelligence or mathematical/logical ability. If it all comes in one package, jolly good. However, if I had to choose between a budding physics genius with a highly abrasive personality and a slightly well performing person with good social skills, I'd choose the latter. No question about it.
The owls are not what they seem
http://http://www.softwarereality.com/lifecycle/xp /case_against_xp.jsp
In two minutes I was able to save both myself and my company many man-years and headaches.
I work for a largish (the largest?) media organisation in the world cutting code as part of a team of 4 developers plus a senior developer.
We've been using Scrum and Test Driven Development for about six months now, and there is NO WAY I'm ever going back to writing code without writing tests first.
Scrum (see http://www.controlchaos.com) is a "lightweight" development methodology. It's developer driven (no more gannt charts !!!!), and it's agile, meaning that it embraces change throughout the project lifecycle. I can highly recommend it. But I digress...
Test Driven Development is something that every halfway serious programmer should be doing IMHO. It doesn't replace the initial back-of-a-fag-packet design stage, nor does it stop you designing elegant and effective architectures. What it does do is:
So I can recommend TDD. Check it out. By the way, we're coding mainly in python with some java thrown in too.
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
Check out the work of James O. Coplien. He's an extremely hard core C++ guy, but when he was doing research at Bell Labs, he descovered that organization effectiveness was far more important for software development productivity than any technological advance.
This is exactly the point the XP people are missing. All the practices they prescribe require a very sound organizational culture. Unusually sound. If you already have that in place, then XP might enhance your organization's performance. But if you already have that in place, you've already solved a long list of much harder problems.
And don't get me started on the requirements gathering end of the process: in full XP, you have to collaborate tightly with your business stakeholder folks. You have a problem with the other developers in your own department? Wait till you have to deal face to face with the idiot from marketing or the arrogant ass from finance. A lot.
'In knowledge is power, in wisdom humility.'
On one project, we had a bug that would always cause a segfault at shutdown. No one had ever been able to track it down -- it wasn't hurting anything as far as we could tell, but it was highly annoying. This was a very small shop and we were just starting XP (or any determinable development process, for that matter), so we hadn't been doing much in the way of pair programming anyway.
Myself and another developer tried pairing to find the bug. We talked it out briefly, and decided to do a binary search of the code with print statements (as the debugger couldn't find it). We'd start the program then exit it, trying to find where in the shutdown process the bug was.
We went over the logs together, and the first person to narrow down another potential location. I'd suggest a spot and add a print statement there, then he'd suggest one. We'd then run the program again, collect our logs, and start over. If I got stuck, he'd have an idea and vice versa.
It took us about ten minutes to track it down and figure out exactly what was going on. I'd spent a couple of hours on it alone without making any progress before, and I think he'd done the same. If we'd paired on that before, we'd have saved a bit of time and money.
I'm not sure where you get the idea that pair programming is having some slob sit behind you and breathe over your shoulder. In my experience, it's like having a conversation about code that produces working code. If you can give up the idea that you have to be right and that your way is the best way and, for goodness' sake, hand over the keyboard about half the time, you'll probably find it's a lot more productive and even more fun than working alone.
how to invest, a novice's guide