Comments on: Thoughts and notes on unit testing

By: Todd

Todd — Fri, 01 Jul 2011 18:15:19 +0000

I always found unit tests to have more value in developing then in actually testing. To be able to write tests in first place often requires keep code more loosely coupled, and to abstract IO functions more. It did not help at all in logic bugs or memory leaks. There is still great need for good systems and regression tests.

By: Randell

Randell — Fri, 01 Jul 2011 11:08:53 +0000

Thanks, Pau! I have updated the post to reflect the url change. =)

By: Pau Sanchez

Pau Sanchez — Fri, 01 Jul 2011 10:43:46 +0000

The link about Effective Unit Testing is now broken. The correct link right now is:
http://ubiquity.acm.org/article.cfm?id=358976

I discovered this after trying to read that article

By: Chaviv

Chaviv — Thu, 08 Jul 2010 06:30:16 +0000

The Art of Unittesting is a good introduction to the why’s and how’s of unittesting. Though it’s based on .net, the principle should apply to any language.

http://weblogs.asp.net/rosherove/default.aspx

By: Juho Vepsäläinen

Juho Vepsäläinen — Thu, 08 Jul 2010 05:58:32 +0000

I suppose the main thing about tests is that they work as scaffolding. They don’t guarantee that everything works. They just give you that extra bit of confidence you need when refactoring. It’s easier not to screw something up when you have plainly stated the constraints and corner cases code has to abide to.

Of course tests are not without their problems. If not maintained, you might end up with a mess. Now you have ~two~ issues instead of one. It’s not enough just to write tests. It’s important to keep them up to date and legible.

Sometimes I prefer to use testing to drive my development work. This is particularly handy if I’m familiar with the tool I’m using and I’m just exploring some new domain constraints of which I know. Just recently I wrote a tiny tokenizer this way. I sketched out expected results and wrote the code to comply to my definition. As you might well know this approach is known as Test Driven Development (TDD).

This article covers the basics of the approach well. In addition you might want to check out this presentation to give you some further ideas.

Besides TDD there is a whole family of xDD approaches. These include behavior, documentation, domain, acceptance testing, even bug (ok, this is a joke!) etc. drivers. The key idea here is that you derive the constraints for your code somehow.

The approaches vary based on how they state their starting point. You might want to use something that the customer himself may be able to come up with (stories). Then it’s up to you to map it to something more tangible. You could end up using a tracer bullet approach (Hunt, Thomas) to sketch out the whole app and just fill in the details as you go.

There are many approaches to development and testing altogether. It’s up to you to find the ways that work well in your context. Good luck!