Comments on: How test driven are you?

By: Eric Davis

Eric Davis — Tue, 22 Jan 2008 00:47:42 +0000

I tend to follow TDD very closely but I will break it when needed. I find it gratifying when I can complete the feature without even firing up a web browser.

1. “Is it OK to go to a prototyping mindset every now and then and still think that you’re being test driven?”

Yes. I can’t remember where I read about it (Dr Dobbs?) but there was a study that found even the most Extreme XP shops spent the first iteration planning and doing some up front design.

2. “How strictly are you, other developers, following practices like TDD? Do you think they should be practiced like a religion, or should we be using our common sense and create our own mixes of practices? Why?”

Not like a religion but practiced heavily. If a developer says they completed a feature without adding/changing the tests I will have them prove it to me that it works. Sometimes I will write up test that fails and have them fix it (typically a boundary condition).

3. “And if you’re able to do completely test driven development, what’s your secret? Where do you find the first test? And so on”

I like to build up my trust in the system. My first tests are usually “Did the test data really get loaded?” (Model) or “Is the webpage really displaying or is it redirecting?” (Controller). After that I just start to build upwards. This still takes some design up-front but not much.

By: Jarkko

Jarkko — Wed, 20 Jun 2007 20:28:26 +0000

Jim: Thanks for the tip. Protonotes seems like a pretty useful tool for web based applications. I’ll give it a try at some point.

By: Ed Gibbs

Ed Gibbs — Wed, 20 Jun 2007 19:15:53 +0000

I’m writing up labs for a seminar I’ll present to my staff soon on doing TDD in JSF. My approach since JSF is just another MVC framework I started at the service layer. I assumed I was going to have authentication so I needed a SecurityService. So I wrote tests like testLoginWithGoodUser() and testLoginWithNullUser(). That forced me to implement some sort of user class. When I felt like that was fleshed out enough I dropped into the persistence layer and tested things were being persisted using an in-memory HSQLDB and Hibernate. Then I went back to the controller and wrote tests to actually perform a login. Finally I created a Selenium tests for the front end to test the navigation between pages.

This approach has allowed me to stay almost 100% TDD. Of course the reason I’m writing up the seminar is to convince my developers there is a way to do hardcore TDD in J2EE land even though they often struggle with it. Mock frameworks can help a lot to since you can take out dependencies and do TDD without implementing much of the full stack upfront.

By: Jim Corbeil

Jim Corbeil — Wed, 20 Jun 2007 14:21:46 +0000

I’m totally a sucker for prototyping my way into test driven development. I take it one step further in that I use a prototyping annotation tool like Protonotes (http://www.protonotes.com) to add notes to my prototypes that eventual evolve into my test cases.

By: Carl

Carl — Sun, 17 Jun 2007 17:26:49 +0000

Jake: I never thought about doing it that way, but that is indeed the best of both worlds. Thanks for the insight! i Have heard of developers using VM’s to do this sort of thing but that seems more complicated and less reusable than what you suggest.

By: Jake McArthur

Jake McArthur — Sun, 17 Jun 2007 17:10:04 +0000

I get the urge to prototype a lot, so I do. To keep safe, here is my process:

1. Fork a new branch of the project.
2. Modify it until it has the new functionality I want, then refactor it a bit if necessary. No tests are strictly necessary here.
3. Go back to the original branch and begin the normal TDD/BDD process. Make a test that fails, make it pass, etc. All the while, use your other branch as a reference.
4. Once you are done integrating the functionality into the main branch, trash your prototype. Never look at it again.

I have chosen to slightly modify the process to safely support my natural tendencies. This is the path I think most people should follow. Like Ricky Clarkson says, don’t follow anything religiously. Different methods are better for different situations. However, sometimes it is just better to slightly evolve a process to suit you.

By: taw

taw — Sun, 17 Jun 2007 03:42:00 +0000

I usually use follow TDD when extending existing programs. When I build completely new software I first create a prototype, then I either toss it, and start TDD from scratch, or build on it gradually adding tests and turning it into fully functional software. Maybe you will feel better about it knowing that this pattern has a name ;-). The basic difference between Spike and Big Design Upfront is that the former is "depth-first" and tries to get "something" done as soon as possible (the "something" can then be tossed or not, it's there mostly to help you explore the problem), while the latter is breadth-first and will invariably end up in a disaster if the problem isn't well known.

By: Jarkko

Jarkko — Sun, 17 Jun 2007 02:50:14 +0000

Hey Daniel, thanks for the link! I’ve been reading some blog posts about behavior driven development, but this one cleared many things to me about what’s the idea behind that approach – and how it could help me in the situations described in this blog post.

By: Jarkko

Jarkko — Sun, 17 Jun 2007 02:41:16 +0000

Ricky:
Actually I don’t think the order matters that much – it’s more about whether I write tests or not. In the project I’m refering to all testing was done by using the product in a way an end user would use it. So, there was no automated tests like unit tests present at all. I think that any kinds of unit tests would have made it easier for us to do the changes and thus get the project completed faster.

This approach works pretty well in the sense that we actually did find the problems eventually. But the problem was that it was the QA department who had to look for the bugs and report them to us. So it was quite time consuming. With unit test (or any kind of automated tests) we could have found the problems even before giving the new code to our testers.

To me it seems that TDD’s could be that by following that practice you actually do write the tests, and make your code more testable. And that’s how it can help you avoid chaos.

And well… To be fair, the project I’m talking about wasn’t complete chaos. After all, we managed to get the bugs closed and the product ended up pretty good. But at some point it sure felt like a never ending story. :)

Carl:
I’ve been also looking at BDD and it looks interesting. I’ll have to try it sometimes in the near future as well.

By: Daniel Watkins

Daniel Watkins — Sun, 17 Jun 2007 02:36:35 +0000

Hey,
Just read a blog post about behaviour-driven development[0], which is a process derived from test-driven development. It basically started from the premise that writing your tests in the form ‘shouldDoX’ helps you outline your tests easily.

That said, I always start by writing a bit of code that I know to be correct, writing tests to cover it and then move on with TDD…

[Footnote 0: http://dannorth.net/introducing-bdd/