Normally I would expect that if the test passes in Test Viewer (the UI), then it would also pass when I run it in MSTest from the command line, and it would still pass when I call it from MSBuild. However, I found this not always so.

One of my tests wrote out files to the temp directory, as generated by "System.IO.Path.GetTempPath()". I then cleaned up the test output by deleting the directory, and recreating it. This worked fine in both UI, and MSTest, but failed in MSBuild with the following error:

Run Configuration: Default Run Configuration
The batch file cannot be found.
C:\myProject\myBuild.msbuild(21,5): error MSB3073:

The command ""C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MsTest"
/testcontainer:C:\myTests.dll /resultsfile:myOutput\UnitTests.trx" exited with code 1.
Done building target "UnitTest" in project "myBuild.msbuild" -- FAILED.

By appending a sub directory to the temp directory, like "System.IO.Path.GetTempPath()" + "temp\", the tests all passed again. My guess is that MSBuild sent something to this output directory that my cleanup method was inadvertently deleting.

1. Create a test-only instance of the database
2. Initialize the table data to a specific state
3. Run your object
4. Check either the return value of that object (for selects) or the new state of the database (for insert/update/delete).

A common problem I keep facing is that these tests can take long to create, and longer to modify. Below are a few tips that I've been learning.

Creating the initialization script is usually tedious and time-consuming. One approach is to create or find a tool that takes a select statement and generates inserts from its result set (I built such a tool, but I can't release it because it's proprietary to my company, Ameripay). This lets you easily copy existing data for testing purposes.

I modified this tool to put tabs after each column, and place the insert and values sections on separate lines.

insert into myTable ( myId,    col1,     col2) values ( '1',     'abc',     'def')

This lets me easily copy the text into Excel, which then automatically formats it in a tabular way that lines up column headers with contents, like so:

insert into myTable(	myId,	col1,	col2	)
values(	'1',	'abc',	'def'	)

It's much easier to edit this way!

Therefore to maintain the data, I only need the raw SQL script itself - not some fancy generator/mapping tool or spreadsheet. I can now take the raw text and swap it between:

• Query Analyzer -  to easily test it
• Visual Studio - in a source file as the contents of an ExecuteNonQuery(@"...") method that runs it to initialize the test
• Excel - to put it in tabular form and maintain it.

Two applications of this:

1. I created a MasterInserts Excel sheet that contains standard inserts for each table. Therefore if I have 5 objects all requiring test data from the same table, I go to this master sheet as the definitive source, copy the lines I need, and modify them appropriately. This prevents me from wasting time re-creating SQL inserts for tables.
2. Say I have multiple tests for a single object. 90% of the base data for each test is the same - usually it's just tweaking a value like making sure a SP handles a null column. Therefore I refactor the common base script to a single method that runs it in ExecuteNonQuery. Then each test can call this method and merely do the simple update or additional insert that it needs.

The sky is always the limit, but it's getting there.

In this case, the void method Increment() changes the state of the Foo1 object, which can be measured by the Counter property. So, the following would be a decent test:

The intent is that we want to always test deterministic logic, such as code that contains conditions, loops, or operators. While this is straight-forward with static functions (plug in x, get y), it can still apply to void methods. The difference is that a void method may be updating another property of an instantiated object instead of a return value.

However note that void methods may lack any logic to test. For example, the method below simply wraps some architecture block that writes out files. There's no logic here to test.

This article explains some theory behind testing/not testing private methods, and then provides and walks through a downloadable code sample to demonstrate these testing techniques.

http://aspnet.4guysfromrolla.com/articles/012605-1.aspx

I think this is a pretty good tool, especially because it's open source and has a familiar API.

These are practical guides that show how to use Unit Testing to ensure that the code actually worked in the first place and fortify your code against regression bugs. Both books refer to NUnit (http://www.nunit.org/), a Unit Testing tool for .Net based on JUnit. I’ll write the next couple blog entries about useful tips I found from these books.

Where to put your Tests: put them in a separate assembly so that they don’t ship with production code. Although if you put them in the same assembly, you can test for protected members, there is a work around: make a test class that inherits the production class, make the new class have public accessors. I use to use the #if DEBUG … #endif, but I like this approach a lot more.

Write the tests first: I use to develop first, and then write tests to cover my back. Test Driven Development is about writing the tests first, they fail (the implementing code hasn’t been written yet), and then write the code to make the tests pass. This makes you program from a user’s perspective (you need to use your own methods to write them in the tests), and gives you a very objective standard to adhere to. You don’t burden yourself with everything that might happen down the road – just make the initial tests pass. Because you should have sufficient tests to cover all the functionality of your program, you can confidently refactor and add features later without fear of breaking things.

Useful checklists (from Pragmatic Unit Testing in C#):

What to test, use your Right-BICEP:

  Right

  Boundary conditions

  Inverse relationships

  Cross-Check results with other means

  Error Conditions occur

  Performance within bounds

Good Tests are A TRIP:

  Automatic

  Thorough

  Repeatable

  Independent

  Professional

More later