Comments on: Unit testing with Visual Studio 2008 – Part 2

By: Unit testing part 3: Design for testability « Freekshow

Unit testing part 3: Design for testability « Freekshow — Wed, 03 Sep 2008 11:21:47 +0000

[...] @ 11:20 am This is part 3 in a series of posts about unit testing using Visual Studio. Part 1 and part 2 focused mainly on the MS Test environment within Visual [...]

By: joelcochran

joelcochran — Thu, 31 Jul 2008 14:25:17 +0000

Hi Freek,

I’m just getting back to this. It does make sense, and I guess it would be readily apparent to someone with more experience Unit Testing. You are probably right on the alternative approach, it creates more questions that need to be answered. One thing that I failed to mention that I really do like about your approach is its brevity. And now that I understand it a bit better, I’m sure I will be using this going forward.

I do enjoy sharing code, and I never get defensive about it because there is almost always a better way to do things. Thanks to you as well for being willing to share your knowledge and techniques: the community makes us all better developers.

Joel

By: Peter

Peter — Thu, 31 Jul 2008 00:58:35 +0000

Hi Freek,

Thanks for all these useful information on unit testing. For a project which has already started, is that a way to add unit tests programmatically? What is the guideline to separate different tests into different test projects? One area that I want to know more is data-driven unit testing. Do you have information in that area?

Thanks

By: Freek Leemhuis

Freek Leemhuis — Mon, 30 Jun 2008 11:01:03 +0000

Hi Joel,
We are all learning as we go along, and I’ve certainly had plenty of comments on the stuff I write, sometimes there’s no better code review than posting this stuff out into the open! So kudos to you for doing that.
As for the alternative solution you’ve posted above, what if you get a different type of exception then ArgumentException? Will you not get a type conversion error in your catch block?
Using the ExpectedException attribute, you don’t actually need an Assert, the test will fail if the expected exception is not thrown, and succeed if the specified exception is indeed thrown.

By: joelcochran

joelcochran — Fri, 27 Jun 2008 14:17:57 +0000

Yes, as I mentioned in my post, I certainly have much to learn. One of the comments showed an alternate way to do this by creating a local ArgumentException variable and only populating it if the exception was properly thrown:

[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.”);
}

I liked this idea because it limits the method to a single Assertion, which seems like it would be ideal to me. I also like your approach, and I will definitely give it a spin, but what I do not like about it is that it is not readily apparent what the end result will/should be because there is NO Assertion statement.

Thanks for the bits about initialize and cleanup, they will definitely come in handy