http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx

I can’t wait until Orcas ships. Am I waiting on a really cool testing feature … nope. (The ones I am interested in come in Rosario). Do I want to use WPF … nope. Javascript debugger … nope.

I am waiting on VS 2008, so I don’t have to install VS2005 SP1 ever again!!!

I decided to reinstall my laptop yesteday. It took 20 mins to install the operating system, 20 mins to install SQL server, 30 mins to install VS2005, and it has taken 1 1.2 hours to install VS2005 SP1 and it still isn’t finished !

I’m sorry but it should never take longer to install a patch than the origional applicaiton … period. If it does, you might as well add in SP1 out of the box and call it VS 2007.

When Microsoft announced that Whidbey would include unit testing, a lot of people thought that it would mean the death of nUnit as we know it. Well one year later, it seems that rumours of the death of nUnit at the hands of VSTS are very much exaggerated. In-fact I don’t know of a single developer that is using the Microsoft.VisualStudio.TestTools.UnitTesting framework. In this post I offer to the Visual Studio team, some of my thoughts why, in my experience, their stuff is not being adopted with hope that they will correct the situation.
1. You should be able to run nUnit tests in Visual Studio 2005.

Before you run out and say, but you can run unit tests in Whidbey, I am referring to tests that have been written using the nunit framework, using the Test View and Test Manager. You should be able to open a project with nUnit tests and boom, they appear as a test asset like any other in the Test view window. I can’t think of any good reason, commercial or other why you can’t do this, especially as nUnit uses the zlib/libpng license.

2. Unit testing should be in all versions of Visual Studio.

Unit testing is such a fundamental part of modern software testing that it should be a ubiquitous feature. Users of VS professional are not going to upgrade to the VSTS developer SKU for this feature when nunit is available instead. That’s right Mr. architect, no testing for you either.

3. Microsoft’s stuff is better, but no one knows it.

It supports data driven tests, it has implementaiton-to-test and test-to-method code generators. It creates accessors for private methods, but most developers don’t use this stuff. Hardcore TDD guys use resharper, and everyone just creates their test classes by hand.

4. You can’t run tests without a full VSTS license.

You can use MSTest.exe to run tests without Visual Studio, but you can’t escape the fact that to get MSTest you need VSTS. You should be able to call tests programatically without needing the full version of Visual Studio installed.

Essentially, these tools show that no matter how good the tools, if you don’t market them correctly they simply won’t be adopted.

I came a cross a post by the C# Test Manager Rusty Miller where he describes some of the tools that were used to test C# for the Visual Studio 2005 release.

Developing your own, specialised test tools and frameworks is one of the best parts of my job and I am always looking for directions we can to push the envelope, and innovate to make our job easier. It is also a big reason why I think that document heavy approaches like ISO testing standards are have little or no place in the modern software development and testing arena.

From Scrum for Team System, which was found via Rob Caron’s blog post Scrum for Team System Released.

Scrum for Team System is a free Agile Software Development Methodology add-in for Microsoft Visual Studio Team System, developed by Conchango, in collaboration with Ken Schwaber and the Microsoft Technology Centre UK.

Scrum for Team System provides development teams with deep support for the use of Scrum, when running projects using Visual Studio Team System’s integrated suite of lifecycle tools.

Adam Cogan mentioned on his guest appearance on .Net rocks that there was no facility to run Visual Studio 2005 unit tests outside of the IDE. Well I am not aware of a published API or a standalone GUI tool, but I did manage to find a command line tool, MSTest.exe.

On a standard installation it should be located in: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe.

In part 1 (way back in August 2005), we developed a basic unit test that we are now going to data drive to perform all the tests we defined using a cyclomatic complexity analysis of the code.

What is a data driven test?

A data driven test is essentially a normal test that has been wrapped in a loop, and the test is run several times with a different set of values each time. The values can be supplied from any source, such as a csv, excel file or a database. In this example I am going to use the new testing context and a 2005 SQL Express database. Using an MDF file allows it to be added to the solution along with all the other source files and easily version controlled.

To add a database, with the test project selected, Click on the the Project menu, then Add New Item. When the add new item dialogue appears, select SQL database. I am going to call my database TriangleTests.mdf. Ok, assuming the database creation has worked for you, (there was a bug in beta 2), we will now continue on our merry way and create the TestData table in our new database with the following SQL.

CREATE TABLE [dbo].[TestCases] {
	[TestNumber] [int] IDENTITY(1,1) NOT NULL,
	[FirstValue] [int] NOT NULL,
	[SecondValue] [int] NOT NULL,
	[ThirdValue] [int] NOT NULL,
	[Result] [nvarchar] (50) NOT NULL,
	[IsNegativeTest] [bit] NOT NULL,
	[TestDescription] [nvarchar] (50) NOT NULL
} on [PRIMARY]

Modifying our existing test

Once our database has been created, we will modify the existing test shell to add a TestProperty attribute that allows us to access the data in the table using the new TestContext. We will also modify the test itself to read the values from the database instead of hard coding them.

The easiest way to add the DataSource attribute is to select CheckTriangleTest in the TestView window then click on the ellipsis in the empty Data Connection String field in the property window. Then, select the TriangleTests.MDF file and the TestCases table using the drop down in the Data Table Name field. We also need to remove the hard coded values and use trhe TestContext.DataRow Our test now looks as follows:

[TestMethod()]
[DataSource("System.Data.SqlClient",
    "Data Source=.\\SQLEXPRESS;AttachDbFilename=\"Your Connection String",
    "TestCases", DataAccessMethod.Sequential)]

public void CheckTriangleTest()
{
    int a = (int)TestContext.DataRow[1];
    int b = (int)TestContext.DataRow[2];
    int c = (int)TestContext.DataRow[3];
    string expected = (string)TestContext.DataRow[4];
    string actual = Teknologika.Samples.Samples.CheckTriangle(a, b, c);
    Assert.AreEqual(expected, actual, "CheckTriangle did not return the expected value.");
}

Implementing the CheckTriangle method

To implement our CheckTriangle method, I am just going to cut and paste the code that we wrote previously, as the CheckTriangle implementation in Samples.cs.

public static string CheckTriangle (int a, int b, int c)
{
    if (a <= 0 || b <= 0 || c <= 0)
    {
       return "Illegal Triangle";
    }

    if ((a > b + c || b > a + c || c > a + b))
    {
       return "Illegal Triangle";
    }

    if (a == b && b == c)
    {
       return "Equilateral Triangle";
    }

    if (a == b || b == c || a == c)
    {
       return "Isosceles Triangle";
    }

    return "Scalene Triangle";
}

With the method now implemented, all we need to do is to add the tests we defined to the database and then run our tests. This approach significantly reduces the lines of code needed to execute all the paths through our code and allows new tests to be added quickly, and easily.

Now that I have installed Whidbey Beta 2. I thought that I should implement the tests I designed in my recent post on using cyclomatic complexity to design tests.

To start, I have created a class library called Samples, with a shell for single static CheckTriangle method. I have added the return null statement so we can compile the class.

The easiest way to setup our test project is to right click on the method name and select create tests.

In the resulting dialog, ensure that I select C# tests in the output project drop-down. For some reason the default is VB, a opposed to the language of the library that you are creating the tests for. I am going to call the project Teknologika.Samples.Tests. Visual Studio will now create a new test project, which includes 2 tests: a UnitTest1.cs class and a ManualTest1.mht manual test.

I am not going to use the manual test, so I will simply delete it. I want to pause here for a second to reflect on what we have already done. In around 30 seconds we have created a new test project and have a test shell ready to run. We have already saved a heap of time that we would normally have to spend creating a new class library and setting up nunit just to get to this point. Cool.

The generated code shell will be the starting point for my tests. To keep things organised I have copied my tests into a text document and added that to the test project. I am also going to rename the UnitTest1.cs file to Samples.Tests.cs so it corresponds 1:1 with my class’ implementation. So after the tidy up, this is what my solution now looks like.

The next thing we need to do is to create a default test script that we will data drive. I have changed the generated test into the following:

Once the test finished, and the solution is finished, we should jump in to the Test Manager, by selecting Manager and Execute Tests on Visual Studio’s new test menu, then select and run out test which should pass.

In the next post, we will complete the CheckTriangle method and change this test into a data driven one.

After playing around with the vpc image of Beta 2 for a couple of days, I finally decided to install the beta onto my home machine.

With disk space limitations, I choose to install a cut down release which only included c# and no team foundation client, only to be greeted by the following error:

A quick search in the product feedback centre soon revealed that the issue had been found and logged, and I needed to have Team Foundation Client installed to stop the error from occurring.

Having external access to the issues is a great feature that I will have to incorporate into our own internal defect tracking system, and I hope someone develops something similar to sit on top of a VSTS database.