Comments on: First Foray into Unit Testing with Visual Studio 2008

By: Dot Net Nerd

Dot Net Nerd — Mon, 01 Dec 2008 10:48:46 +0000

Unit Testing in Visual Studio…

Unit Testing in Visual Studio…

By: Joel

Joel — Tue, 12 Aug 2008 14:49:10 +0000

That’s a great point Chris. I’m sure we all know that once we write it, it is ours forever (or at least as long as we work in the same place).

To be clear, though, this is what I said:

…you would easily write tests to support or validate what you’ve already done. In my mind, that defeats the purpose.

What I mean by this is that when writing tests after the fact, we have to be careful to make sure they are testing the intent of the code and not just verifying the result we are already getting, since the two may not match. I do agree that adding the tests has value, we just can’t cook the testing books so to speak.

By: Chris Salter

Chris Salter — Tue, 12 Aug 2008 14:25:58 +0000

One thing I’d like to respond to in the comments here… Adding unit tests that validate what you’ve already done doesn’t defeat the purpose at all. You might not be getting the full benefit, but it’s still valuable. If you ever have to come back to that code and make changes, having the tests gives you a much better chance of picking up any bugs you might happen to introduce.

If anything, my experience has been that in the long term, unit tests are really handy up-front but the real value is in the confidence they give you when you inevitably have to modify the code later… especially after your old, half-forgotten tests have caught a few bugs for you…

By: Unit testing with Visual Studio 2008 - Part 2 « Freekshow

Unit testing with Visual Studio 2008 - Part 2 « Freekshow — Thu, 26 Jun 2008 15:41:31 +0000

[...] A lot of times I’ve seen developers using a try/catch block to test for exceptions. Joel for example has posted this little code snippet: [...]

By: Joel

Joel — Thu, 19 Jun 2008 14:08:31 +0000

I think that’s a big part of it Thomas. I frequently find myself starting to code with a rough idea of what I want, but without much of a game plan. When I realize I’m doing this, I try to stop and at least outline what it is I want to accomplish. I think by writing the tests first, you start with two important pieces of information: the definition of success AND the definition of failure. Since everything other than success constitutes failure, and we start without success, it makes sense to start with a failing test and code *just until* we achieve success.

By: Thomas Eyde

Thomas Eyde — Thu, 19 Jun 2008 13:50:39 +0000

I read the other day, I don’t remember exactly where, but it said that writing tests first make us focusing better on the task at hand, and that activity alone makes the quality go up by an order of magnitude.

By: Dan Blair

Dan Blair — Mon, 16 Jun 2008 16:44:15 +0000

The just in case methods are the first things that I saw go when we started focusing on using unit tests. If you write what you need, you know when your done, have a reasonable expectation of it being correct, and the code should be more maintainable.

I come across code all the time that’s 8 year old “just in case” code that has never been used. Some of it took several weeks/months to develop, we really do nobody a service by creating such things.

By: Joel

Joel — Mon, 16 Jun 2008 13:02:07 +0000

Oh, I like that! Yes, I have plenty to learn. I don’t think adding them after the fact is difficult, per se, but I can see where you would easily write tests to support or validate what you’ve already done. In my mind, that defeats the purpose.

Also, one of the articles I read mentioned that by using TDD, you only develop the code you need. I have a tendency to write a bunch of overloads and methods “just in case”, so this will be a great benefit for me. I think ultimately it will make me a faster coder, and I’m sure a more productive one.

By: Thomas Eyde

Thomas Eyde — Sat, 14 Jun 2008 18:00:46 +0000

As you have discovered, adding unit tests after the fact is very hard work. I can tell you, once you get the habit of writing them first, one by one, you will find them easy to write and quite indispensable.

A tip for the tests you have shown us here:

The assertion message is only displayed when something is broken, hence you want the message to explain what’s wrong. The way you have written these tests, the second assertion will always be true and the message never displayed.

If you are comfortable with empty catches, you can just delete the second assertion.

If the exception type is important, you could write the test as follows:

[TestMethod]
public void TestZipCodeNumericButGreaterThan99999()
{
TransactionRequestInfo req = new TransactionRequestInfo();
string testValue = “58634789″;

ArgumentException thrownException = null;
try
{
req.Zip = testValue;
}
catch (ArgumentException aex)
{
thrownException = aex;
}

Assert.IsNotNull(thrownException, “Proper exception not thrown.”);
}

By: Joel

Joel — Fri, 13 Jun 2008 13:53:19 +0000

Thanks, I’ll be sure to read it.

Even with my extremely limited experimentation I can see that they are going to become a staple of my development diet. I know there are people who are diehard NUnit fans, but I’m sure it really doesn’t matter what flavor you prefer. For me, I’ll probably stick with the built in Testing mechanism, just because it is easy and readily available.