Unit Testing

I have released a new site where I will publish “howto” articles on unit testing, and automated testing in general.

Check out the new site at http://www.unit-testing.net/

I plan to publish new articles every week.

Unit tests and Use Cases

A common challenge when writing unit tests for a large code base is keeping track of what you are testing. Without a good process for categorizing what the individual tests are actually testing, it can quickly become unmanageable. This is especially true for projects with several hundred tests.

The way I have decided to tackle this challenge in ExpressUnit is through use cases. For those of you unfamiliar with the concept of use cases, here’s the Wikipedia definition:

“A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes “who” can do “what” with the system in question. The use case technique is used to capture a system’s behavioral requirements by detailing scenario-driven threads through the functional requirements.”

Source: http://en.wikipedia.org/wiki/Use_case

Since use cases are a description of how the system should behave, I find them to be a very natural grouping for unit/integration tests. The mechanism for grouping tests by use cases in ExpressUnit is actually quite simple. I have simply extended the test attributes (UnitTest/IntegrationTest) to take in an optional use case parameter. The new syntax works as follows:

 [UnitTest(UseCase="Confirm.Equals will return true if objects are equal")]

public void ConfirmDoubleObjectsAreEqualTests()

{

    Confirm.Equals(1.0, 1.0);

}

The above example is from ExpressUnit’s own Confirm test suite where all Confirm.Equals tests have been linked to the use case: “Confirm.Equals will return true if objects are equal”.

Version 3.2 of ExpressUnit contains a new UI window for displaying test results broken down by use cases. (See Figure1). You can navigate to this window by clicking the Use Case tab after running all your tests.

Figure1

Continuous integration: ExpressUnit and Hudson

To manage large software projects with many developers and a large code base, it’s very useful to automate builds and test runs through continuous integration. The most common setup is to have a continuous integration server build your source code and run all your tests on code check-in. This gives you almost immediate feedback on whether or not your latest code check-in broke the build by either causing a compiler error or test failure. There are several alternatives out there for continuous integration. I have chosen to integrate ExpressUnit with Hudson which is an open source continuous integration platform. The nice thing about Hudson is that it’s very easy to configure. The interface is extremely user friendly and lets you handle everything through a simple web based UI. I won’t go into much detail on how to set up Hudson as there are plenty of good tutorials available on the web. Instead I will list some of the necessary steps to integrate ExpressUnit with Hudson

1)Add your source code management tool through the Hudson web UI

2) Set up MsBuild as your source code builder (point to your solution file)

3) In the Windows batch command window make a call to “ExpressUnitGui.exe runtests” which triggers ExpressUnit to run and close after all tests have been run (No user interaction required)

4)Select to publish JUnit test result report. ExpressUnit will, when running in command line mode, generate an xml file with test results which will be picked up by Hudson and displayed in the UI. The generated xml file is compliant with the JUnit test result format required by Hudson, so Hudson will be able to display information about your test runs. You will be able to see statistics of test runs over time as well as information about why particular tests failed.

I am actually using ExpressUnit as my testing framework while building ExpressUnit. The following screen shot shows my ExpressUnit project on Hudson

Figure1

On the left you can see the build history, and over on the right is the test trend graphed over time.

Please drop me a line if you need more detailed instructions on how to get ExpressUnit up and running with Hudson

Is pure TDD practical?

 

As a software developer I have always considered unit testing an important asset to programming. Most developers who do unit testing will naturally develop their own style and technique for writing tests. However many have started to embrace a new paradigm called Test Driven Development (TDD).

TDD mandates that the unit test must be written before the actual implementation of the code you are testing. I like this idea in principle, but I argue that it might not always be practical. Instead I practice what I call ATDD – Almost Test Driven Development. The difference is that I implement my code before writing the unit test, but I always envision what the test will look like before writing any code. When creating the test, I may also debug into my new code to capture output that I can use in the Assert statement of my test. This clearly violates the TDD paradigm since I already have an implementation to test. However, I feel this is more practical since it may save me a lot of typing if the result value of my code is complex and hard to produce manually. This is especially true if the output is a long complex string / xml. It is of course very important to be very careful when manually inspecting the result of the method.

Another problem I have with the pure TDD approach is compilation overhead. In large .Net solutions it is not always practical to compile and re-run your tests for every little change you make to a method while it is being created. I therefore believe the most practical approach is to implement your code first, but do so with the unit test in mind.

Bulk Insert Sql Server

In one of my recent projects I needed to import data from tab delimited files into an SQL Server database. I decided to go with the Bulk Insert option. Bulk Insert is a neat little T-SQL function that lets you import tabular data from a structured file to a corresponding database table.

Here’s an example of how to use Bulk Insert

BULK INSERT Customer
FROM ‘c:\import\customer.txt’
WITH
(
  KEEPNULLS,
  FIELDTERMINATOR =’\t’,
  ROWTERMINATOR =’ \n’

)

The above code samples imports tabular customer data from customer.txt, and inserts it into the Customer table.  It’s important that the column in both the file and the table are in the same order.

My project called for a tab delimited file, but you can use whatever delimiter you like. Other typical formats you might see are comma separated files (csv) and | separated files.

One thing to keep in mind: Don’t represent null values using some variation of a “null” – string since this will be seen as a regular string, which will fail if you try to insert it into a non char column (or a char column too small to hold your null string). You should instead leave it as an empty value in your delimited file.

More information and documentation can be found here:

http://msdn.microsoft.com/en-us/library/ms188365.aspx

 

Unit Testing in Visual Studio Express 2008

This article has been moved:

New url:

http://www.unit-testing.net/CurrentArticle/How-To-Write-Unit-Tests-In-Visual-Studio-Express.html

Unit testing in Visual Studio Express II

In a previous blog entry, I talked about how you can add unit testing capability to projects in Visual Studio Express by using Nunit.

Instead of using the Nunit Gui client, you can automate the test run by using a post build event and the console version of the Nunit client.

To automatically run your tests when building: Add the following line to your Visual Studio post build event:

“[Local Nunit path]\nunit-console.exe” $(TargetDir)MyTests.dll /xml $(TargetDir)results.xml

This will start Nunit (behind the scenes), and run all tests defined in MyTests.dll. The test results are written to results.xml.
It is worth noting that the build will fail if any of the unit tests fail.

Linq

Version 3.5 of the .Net framework introduced Linq as new way of dealing with object models.

I haven’t had time to play with Linq extensively, but my impression so far is good.

Linq uses a model where content from your data source is mapped into objects, or entities if you like that notation better.

A typically Linq scenario is to build an object model around a relational database where each table will be represented by a typed object in your object model. The Linq framework will aid you in generating the actual entity classes and all CRUD statements. The framework will also maintain/expose a data context which serves both as your connection to the database, and your channel for invoking actions on your data source. The data context will do all the book-keeping of object state (insert, update, delete) as well. The only requirement is that you keep the context “alive” until all changes have been submitted to the database.

Linq can also work with other data sources such as Xml, but if you ask me; its real strength comes from the ability to query typed objects in collections. Any collection implementing IEnumerable<T> can be queried using Linq. This can save you a lot of “foreaching” when trying to filter a collection based on specific parameters.

The syntax of a Linq query resembles Sql syntax, which makes it an easy transition if you have some experience writing basic Sql.

Unit testing in Visual Studio Express

This article has been moved.

New url is:

http://www.unit-testing.net/CurrentArticle/How-To-Write-Unit-Tests-In-Visual-Studio-Express-Using-NUnit.html

Removing data dependency in unit tests

This article has been moved

The new url is http://www.unit-testing.net/CurrentArticle/How-To-Remove-Data-Dependencies-In-Unit-Tests.html