views:

2049

answers:

3

I know Visual Studio offers some Unit Testing goodies. How do I use them, how do you use them? What should I know about unit testing (assume I know nothing).

This question is similar but it does not address what Visual Studio can do, please do not mark this as a duplicate because of that. Posted as Community Wiki because I'm not trying to be a rep whore.

A: 

The unit testing structure in VS is similar to NUnit in it's usage. One interesting (and useful) feature of it does differ from NUnit significantly. VS unit testing can be used with code that was not written with unit testing in mind.

You can build a unit testing framework after an application is written because the test structure allows you to externally reference method calls and use ramp-up and tear-down code to prep the test invironment. For example: If you have a method within a class that uses resources that are external to the method, you can create them in the ramp-up class (which VS creates for you) and then test it in the unit test class (also created for you by VS). When the test finishes, the tear-down class (yet again...provided for you by VS) will release resources and clean up. This entire process exists outside of your application thus does not interfere with the code base.

The VS unit testing framework is actually a very well implemented and easy to use. Best of all, you can use it with an application that was not designed with unit testing in mind (something that is not easy with NUnit).

Eric
care to link/explain NUnit?
Malfist
Why is that not easy to do in NUnit? NUnit provides the same ability to do test setup/teardown. You can use NUnit to unit test code that wasn't written with unit testing in mind as well.
Scott Dorman
Perhaps I misunderstood how NUnit works, but I thought that you have to place declaritive statements wihtin the code you are testing so NUnit knows where to find the test subjects. With the test framework built into VS, this isn't necessary. Although I could be wrong about NUnit. :)
Eric
NUnit is a library of code designed to facilitate automated unit testing of .Net code libraries (there are versions for other languages as well). You can find it here: http://www.nunit.org
Eric
+1  A: 

First thing I would do is download a copy of TestDriven.Net to use as a test runner. This will add a right-click menu that will let you run individual tests by right-clicking in the test method and selecting Run Test(s). This also works for all tests in a class (right-click in class, but outside a method), a namespace (right click on project or in namespace outside a class), or a entire solution (right-click on solution). It also adds the ability to run tests with coverage (built-in or nCover) or the debugger from the same right-click menu.

As far as setting up tests, generally I stick with the one test project per project and one test class per class under test. Sometimes I will create test classes for aspects that run across a lot of classes, but not usually. The typical way I create them is to first create the skeleton of the class -- no properties, no constructor, but with the first method that I want to test. This method simply throws an NotImplementedException.

Once the class skeleton is created, I use the right-click Create Unit Tests in the method under test. This brins up a dialog that lets you create a new test project or select an existing one. I create, and name appropriately, a new test project and have the wizard create the classes. Once this is done you may want to also create the private accessor functions for the class in the test project as well. Sometimes these need to be updated (recreated) if your class changes substantially.

Now you have a test project and your first test. Start by modifying the test to define a desired behavior of the method. Write enough code to (just barely) pass the test. continue on with writing tests/writing codes, specifying more behavior for the method until all of the behavior for the method is defined. Then move onto the next method or class as appropriate until you have enough code to complete the feature that you are working on.

You can add more and different types of tests as required. You can also set up your source code control to require that some or all tests pass before check in.

tvanfosson
Why use TestDriven.Net? That doesn't answer the question at all (which was about using the built-in testing tools).
Scott Dorman
You're still using the Microsoft testing framework, but just using the test runner from TestDriven.Net. I prefer it as it is more convenient to run the tests directly from the code.
tvanfosson
+2  A: 

Easily the most significant difference is that the MSTest support is built in to Visual Studio and provides unit testing, code coverage and mocking support directly. In order to do the same types of things in the external (third-party) unit test frameworks generally requires multiple frameworks (a unit testing framework and a mocking framework) and other tools to do code coverage analysis.

The easist way to use the MSTest unit testing tools is to open the file you want to create unit tests for, right click in the editor window and choose the "Create Unit Tests..." menu from the context menu. I prefer putting my unit tests in a separate project, but that's just personal perference. Doing this will create a sort of "template" test class, which will contain test methods to allow you to test each of the functions and properties of your class. At that point, you need to determine what it means for the test to pass or fail (in other words, determine what should happen given a certain set of inputs).

Generally, you end up writing tests that look similar to this:

string stringVal = "This";
Assert.IsTrue(stringVal.Length == 4);

This says that for the varaible named stringVal, the Length property should be equal to 4 after the assignment.

The resources listed in the other thread should provide a good starting point to understandng what unit testing is in general.

Scott Dorman
I know (think) MS bought TypeMock, but I understood that it was still an add-on. I've got the Team Suite edition and don't have a built-in mocking framework. I use RhinoMocks for mocking.
tvanfosson
@tvanfosson maybe it isn't really mocking then. i was referring to the ability to create "private accessor" objects to allow you to test private and internal methods.
Scott Dorman