One of the common arguments against Test Driven Development is that a lot of the code we write (simple getters and setters, dumb parameterized calls against a proven API, etc.) has behavior that is too simple to bother testing.

I won't necessarily disagree that there is some code that is too simple to be worthy of writing tests for. However, I will argue that you should almost never be writing such code . . .

[More]

Don't Repeat Yourself is one of the most important principles from the Pragmatic Programmers book.

Dan North has posted an interesting article suggesting that maybe there are times where a little less DRY (in your test cases) makes for a little more readable. Check out the comments and associated links as well.

What do you think? Input appreciated!

Stephen Moretti just wrote up a nice review of the pair programming session Ben and I just did for the Scottish ColdFusion Users Group (including a link to the recording) . . .

[More]

As reported on Stephen Moretti's blog, next Thursday at 3pm EST (8pm British Summer Time) I'll be pair programming using TDD with Ben Nadel for the SCFUG.

I paired with Ben last night and thoroughly enjoyed the process. It makes it much easier to stick with the TDD when pairing and one of my goals this year is to pair with a number of good programmers as I think you can learn a great deal by watching how other people approach projects.

Anyway, check out the announcement and sign up for the fun!

Neither Ben nor I have ever paired and neither of us have much experience with Test Driven Development, but last night we spent a couple of hours pair programming and developing a new BaseObject for a project using TDD in MX Unit . . .

[More]

Wondering what Behavior Driven Development has to offer if you already do Test Driven Development? Here are some ideas.

Marc just wrote a really nice post about a specific case where old code was hard to test because of a session reference within the code.

Even worse examples are methods that call (for instance) now() and then perform a calculation on it. If you do so, you end up with a method you can't test for edge conditions around midnight unless you stay up all night. Tests should be repeatable. If they depend on the state of an external resource (system.time, file system, db, etc) you better have a system of fixtures for putting them into a known state or expect a world of hurt.

In other news, I've been asked for some postings on testing queries. I'll try to get that far in the LightBase rewrite within the week so I can show some strategies for testing both specific sql queries and a generic db abstraction layer (my in-house ORM) using a combination of a simple dbUnit style port, mocking and some other ideas.

In the meantime, check out Marc's post. Anyone else got similar examples of problems they've run into when trying to write tests after the fact?

Many of the developers I know have a lot of experience with Unit Testing and Test Driven Development, but I really think that the Behavior Driven Design team have some of the most interesting and evolved ideas on TDD. They understand the critical importance of language in test as well as program design, and I was lucky enough to get a few minutes with Liz Keogh yesterday to help me get started with naming my tests . . .

[More]

One of the things I've heard time and time against is that the best way to learn TDD is to pair with someone who's been doing it for a while to get "test infected". Unfortunately I don't have someone to pair with who has TDD experience, so I've been "infecting myself". Here are some of the things that I've been doing and how it's been working out for me . . .

[More]

I've read a number of books either about Unit Testing and TDD or that include information about them. Here are the resources I've found most helpful. Any other recommendations appreciated . . .

[More]