Slashdot Mirror
Test Driven Development Examples?
esnyder queries: "I find the pragmatic/agile/XP hype about test driven development compelling, but find it hard to see how to test first (or even unit test at all) in some situations. I would like to explore some extended examples of it in a moderate to large scale real world codebase to improve my test design skills. Can anyone recommend some F/OSS software projects that consistently use test driven development processes that I could check out? Preferable over 50K lines of code, but I'd welcome pointers to anything that people think would be helpful."
Where I work we're coding a dating site. Currently, it's up to about 180K lines of scripts written in PHP. However, not a lot of it was written with unit testing (and test-driven development) in mind. I'm a big believer in unit testing but it's been hard to get the other members on board as they complain how hard it is to write unit tests for web pages. Bah.
So, most of the library functions that I wrote (stuff like except an integer, return a text string from a list) have been unit tested by myself, and every time I change a function or a class, I try and write a unit test for it.
Seriously, you just need to dive right in and think about how you make your code easy to test. I use the SimpleTest testing framework (it's PHP), and I always feel good when my array of tests all run correctly when I make a major change to the code that impacts a huge portion of the site.
If test-driven development has done one thing, it's forced me to carefully examine my code to create a way to make sure it is actually working according to the business logic we've been asked to implement.
The first wow, that's cool moment I had with test driven development was from an article on Object Mentor called The Bowling Game. It also highlights pair programming a bit.
The unique thing about the article was that it was presented as a discussion between two developers pair programming doing agile test driven development of the game. It was like watching over their shoulders.
If you want to get an idea of what extreme programming is like, I suggest reading this article AND writing the code and tests along with it, either in Java (and JUnit) or C#/VB.NET (and NUnit) or another language with a xUnit unit testing framework. Most object oriented languages have them now so you don't have to roll your own framework.
----- rL
I've given it enough of a chance that I wrote unit tests for about 3 small projects and developed my own framework for it.
I had three primary problems with it.
#1: My biggest problems always revolve around the user interface. Users encounter FAR more bugs than my internals do, and I never found a good way to unit test GUIs.
#2: I spent many hours developing tests for things that ended up rarely/never choking my tests, meaning they rarely/never caught any bugs. Yet, I still had bugs to work out. I found that it just wasn't worth the time.
#3: Whenever I re-factor, unless I'm Mr. Perfect and all my interfaces are perfect from the get-go, I end up having to edit a bunch of unit tests to match up with the new, re-factored code.
I know the party line on this, but I think it's just the current fad.
I have developed code of significance without unit testing, and I can assure you that the quality of that code was far inferior to the quality of the code developed with more attention paid to unit tests. In the projects I've worked on, sometimes the manager has made the decision to skip unit tests in order to concentrate on features. It's true that those features can be worked on at a faster rate, and seemingly completed sooner. But inevitably, the number of bugs found in QA, and the amount of time spent revising the code eats up any savings. Even if we break even, in terms of time (which, in my experience, would be a generous assumption), then the non-unit-tested project finishes at the same time but has no suite of tests to carry forward to the next version.
Furthermore, the benefits of testing are not just related to finding bugs sooner in the initial version. The tests can help influence the design of the code. I've written code where I ended up refactoring it completely while writing the tests, because the initial version, while it worked, didn't wasn't easily testable or had too many redundancies in the code. The quality of the run-time product was the same, but the source code improved dramatically just because I wrote tests for it.
Also, having the unit tests is a good way to ensure that bugs aren't introduced later. In short, the benefits are so high that, while I can imagine (and have actually done it) working on a project with no tests, it's not a task that I would welcome. It's similar to asking me to work on a task with no debugger, or no source-code control system. Yes, it's possible, and heck, the Linux kernel was written without either of these things, but realistically these are vital tools for software development. To me, unit tests are another of those vital tools.
#1: No, the bugs aren't in the UI itself, the bugs originate through the UI. Users can do things in such a way that you simply can't predict.
#2: But you know, if you have time, there are LOTS of things you can do that might help, or might not. I stopped writing unit tests thinking that they one day *might* catch a bug. If I don't have an immediate or at least imminent benefit from it, I don't do it. It's simply a waste of time.
#3: I don't hack away at code, so I don't think unit tests will save me from something I don't do. My interfaces are developed exactly at the level of quality called for; no more and no less. So in the sense that unit tests can help me "think"...I never found myself lacking in that area. Perhaps it's something that helps less experienced programmers ramp up...I don't know. I've been programming for 20+ years and I'm alright in that regard.
Is it the reason it took forever to develop it? 3X was promised last summer, but it's still in its "early stage". E17 is being developed faster.
Less is more !