VB.NET Testing Frameworks for small projects?

I know this question has been asked before, but none of the existing SO questions provide an adequate answer for my specific case.

I'm the lone developer working on a project mostly during free time. I'm approaching 100 classes so far, and I'm starting to realize that testing that many classes is becoming daunting. Especially as I go back and add in operator overloads for =, <>, CType, and Not; implement IComparable(Of T), IEquatable(Of T), IEqualityComparer(Of T); and overriding base methods like Equals and GetHashCode.

My current testing method has been to randomly scribble out some Debug.Print code for a specific class/method on a dummy form behind a single button, run the project, click the button, and make sure the Debug window has my expected value. But this is both tedious and starting to become a time waster.

What I know that I need to do is for each and every class, draft up a set of tests specific to that class to test its functionality. So I go and look at testing frameworks like NUnit, Gallio/MbUnit, etc. But I really don't see the value in them. It so far seems that I could just write a dedicated test class for each implemented class, wrapped in #If DEBUG/#End If blocks, and link those to a bunch of buttons on a large form to run my tests.

But that could take weeks at my current rate. So I ask SO for their opinion on how to approach something like this. Am I better off figuring out how to integrate one of these open source testi开发者_开发问答ng frameworks into my project? Or should I just write a bunch of testing classes and output their data somewhere?

I use VB Express 2010 and VS 2010, depending on which computer I'm on so I'll need to be able to do testing in both. I'm not going to convert the project to C# anytime soon, so I'd appreciate answers that are compatible with VB.NET.

Thanks!

Since you gave no example how your tests look, I assume that your tests are design by contract style that check parameters and (intermediate) results while executing some functionality in DEBUG builds. This is a perfect solution that makes sure that there are no wrong results while performing a certain task.

The debug output is valuable while implementing a new feature.

The drawback of your current solution is that there is only a verification error if the functionality is executed and the debug output is manually verified. You have to manually trigger every function to make sure that the program still works as expected.

Since your test procedure is usually only executed when you implement or extend some functionality "A", but not if you change code for feature "B" that should not be related to "A". Often "A" and "B" are indirectly related, and implementing "B" will break "A". This is called a regression error.

With NUnit and similar systems you can make sure that all functionality is tested if you run your test suite.

However, it is much more difficult to write and maintain unit, integration, and end-to-end tests with NUnit than applying DesignByContract tests or manuallyVerifyDebugOutput tests.

On the other hand, when doing test-driven development with unit tests, you gain extra architectual benefits for your application.