Geekality » TDD

Test-Driven Development: By Example

Torleif — Tue, 01 Dec 2009 17:36:16 +0000

Book cover

I earlier wrote about the book, The Art of Unit Testing, which I finished a while ago. That book was very good and was focused on how to write good unit tests. It also mentioned Test-Driven Development, TDD, but not too much. The book I read next, which I finished a few days ago, was kind of the other way around. Pretty much only about TDD. And from the title, Test-Driven Development: By Example, that shouldn’t be much of a shocker

The book is written by Kent Beck and explains the basics about TDD. It does this pretty well, step by step, by example, just like the title says. The book also talks some about TDD in a more general sense. What it is, how it works, why it works, et cetera.

From the back-cover:

Readers will learn to:

Solve complicated tasks, beginning with the simple and proceeding to the more complex.

Write automated tests before coding.

Grow a design organically by refactoring to add design decisions one at a time.

Create tests for more complicated logic, including reflection and exceptions.

Use patterns to decide what tests to write.

Create tests using xUnit, the architecture at the heart of many programmer-oriented testing tools.

It pretty much kept the promises The only part I didn’t really like about this book was that I found much of the coding kind of messy. Could be because the languages used in the examples are Java and Python, which I don’t really like that much syntax-wise. An even more important reason though, is that I just finished reading The Art of Unit Testing So, I suppose I have become a bit demanding when it comes to cleanliness when coding and writing unit-tests. I suppose that is a good thing (I do however not claim in any way that the code I currently write is extremely clean in any way! But I do strive for it to be so ;)

I can really recommend this book to anyone who are curious to get familiar with TDD. I certainly see the value of doing TDD and is in the process of trying to incorporate it into my development habits.

Red — Write a little test that doesn’t work, and perhaps doesn’t even compile at first.

Green — Make the test work quicky, committing whatever sins necessary in the process.

Refactor — Eliminate all of the duplication created in merely getting the test to work.

Red/green/refactor — the TDD mantra.

You can get it at Amazon, and probably a lot of other places too as it is a pretty well-known book.

C#: How to test asynchronous events

Torleif — Thu, 26 Nov 2009 18:59:59 +0000

The other day I had to test that an event was raised after some asynchronous work had been done. And since I currently am a total test newbie, this was a new thing for me. Say we have this simple shell of a class:

public class Worker
{
public event EventHandler<EventArgs> Done;

public void Start()
{
...
}
}

Let’s just assume it does some work, and is supposed to raise the Done event when it is… well… done.

Synchronous worker

If the Worker class works synchronously, it would be no problem at all to test it. For example:

[TestFixture]
public class WorkerTests
{
[Test]
public void Start_WhenFinished_DoneEventIsRaised()
{
var worker = new Worker();

var eventWasRaised = false;
worker.Done += (s, e) => eventWasRaised = true;

worker.Start();

Assert.That(eventWasRaised);
}
}

We simply add an event handler which sets a boolean flag when called, start the worker and then check if the flag was set or not. Easy peasy.

Asynchronous worker

What now if the Start method just sends the work to a new thread and returns immediately? Our current test can not be trusted at all in that case. It might pass and it might fail. Most likely fail. All depending on if it managed to finish its work and raise the event before we check the flag. And that would be unlikely to happen. Highly unlikely.

So what do we do? We use a ManualResetEvent instead of the boolean flag:

[TestFixture]
public class WorkerTests
{
[Test]
public void Start_WhenFinished_DoneEventIsRaised()
{
var worker = new Worker();

var eventWasRaised = new ManualResetEvent(false);
worker.Done += (s, e) => eventWasRaised.Set();

worker.Start();

Assert.That(eventWasRaised.WaitOne(500));
}
}

Instead of checking that a flag has been set, we check that the event handler gives us a signal within a certain period of time. If it doesn’t give us that signal we can assume that the event was never raised or that the work simply took longer than we expected. Either case could probably be of interest

Brilliant, simple and readable. Just how we like it

Credits

I am still a total testing newbie at the moment and didn’t have a clue what to do, so after some failing google-fu I asked a question about it at StackOverflow. My solution is based on one of the answers I got there

The Art of Unit Testing

Torleif — Tue, 03 Nov 2009 21:04:42 +0000

Have you gone through three years of computer science bachelor degree fun (or anything similar) and pretty much not heard a word about testing? Or have you heard from all your teachers that testing is extremely important, but never learned how to even write one? That has been the case for me. Testing is important, you all got to do it, it is very important, always test, do it a lot! Well, sure… but how do I do it? How do I write one of these tests?

The last book I finished is called The Art of Unit Testing, and I am so happy that I stumbled over that book. Spring 2009 I was at a developer conference called NDC 2009 (Norwegian Developer Conference) and it was really great. If you have the time, you should go to that website and have a look. You can watch most of the talks there online. Anyways, the second day I attended a series of talks about Test Driven Development with a great speaker called Roy Osherove. I learned a bunch and decided that TDD looks like something I should try to learn. However, I had a big problem. I didn’t even know how to write a test. And doing TDD without knowing how to write a test is kind of difficult… to say the least…

Anyways, this Roy Osherove person advertised that he had just finished a book about pretty much exactly that; writing unit tests. So, I decided to get myself a copy of it.

It was great! Seriously learned a lot. It covers the following subjects (yes, that would be the table of contents).

The basics of unit testing
A first unit test
Using stubs to break dependencies
Interaction testing using mock objects
Isolation (mock object) frameworks
Test hierarchies and organization
The pillars of good tests
Integrating unit testing into the organization
Design and testability (Appendix A)
Extra tools and frameworks (Appendix B)

It is only 283 pages long (including the appendixes) and a pretty quick and easy read. Which I like. I got sucked in, and it was finished fast. Probably should read it again some time But anyways: I previously did not even know how to write a single unit test in any language. Now I do

You can get it from for example Manning (who is the publisher) or from Amazon. I would probably get it from Amazon since they seem to have a 34% discount currently… Except I already have it, of course

If you want to learn how to do unit testing, I can recommend it with all my heart

Oh, by the way, when you buy this book, you even get a free eBook version of it! Which is totally brilliant, since then you can have the book and read it at home, but you can also for example put the eBook version on your netbook and read while travelling. Awesome all the way Wish more publishers or authors (or whoever decides) were like that…

Project Euler: Just two tiny notes

Torleif — Fri, 25 Sep 2009 20:47:34 +0000

Just two things I felt like mentioning:

Thing number one

I got tired of the page 2 stuff. So, I swapped all the things with and a header. Which means that the solution will now be on the same page as the problem. (Although not on the index page).

Thing number two

My brother puts his whole solution on a public subversion repository, which is a very good idea. Following his good example, ~~I did a repository dump of my local VisualSVN Server and… undumped(??) it into one I set up here on my web host which I will be using from now on instead.~~

Update: SubVersion turned out to be a bit blah sometimes, so I am trying out Mercurial now instead. The repository has been converted and published on BitBucket. Mercurial seems a lot nicer than SubVersion so far. You can find a very good introduction at hginit.com.

Thing number three

Ok, ok, the topic says two, but I just figured I should maybe mention one more thing. You see, the code you will find in my aforementioned subversion repository cannot be run. Like, there is no main method or anything there. That is because I am trying to teach myself how to use test cases, etc. So, instead of creating an executable program for each problem or one program with fancy “Solve problem #n”-buttons, I decided to just do it all in test cases. So, my solutions are actually found as part of the test project (well, the running of them anyways). I am using TestDriven.net to run them, and it works great. This way I can also do a lot of changes, and then just run my tests and make sure that all my solutions still calculate correctly. Awesome stuff.