Moq,RhinoMock and Lambda(AAA) expressions

Last time I played with RhinoMock , I was in state of shock and awe. I was awed because it improved my design. It requrired that the code under test should to be isolated from rest of application. That was done using Interfaces . Contract based programming is always best way of programming. I could test behavioral aspect of my code.It would have been little difficult using xUnit framework. It was almost creating a simulation flight envrionment and enjoying the pleasure of real flights.

I was also shocked by the fact that my behavioral tesing Line of codes were many times more than code under test.

I was left in no doubt that Mocking is very powerful and advance technique of TDD. Also at the same time, It will make selling TDD difficult to people new to programming.

Hopefully Lambda expression may help in that direction.

Model/View/Provider and Black Art of Mock Objects

References:
1. http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx

2.

http://www.jpboodhoo.com/blog/AnswersToSomeGoodQuestions.aspx


3. http://blog.vuscode.com/malovicn/archive/2007/02/04/tdd-rhino-mocks-part-1-introduction.aspx


4. Rhino Mock Documentation

No Stubs, No Mocks -- just use ObjectMother -- TDD

http://vikasnetdev.blogspot.com/2006/05/when-to-use-mock-objects.html
Couple of days back, I wrote that I am not using Mock/Stub objects but I have moved creation of my complex business objects in my testing framework to another helper classes. Today I came to know that there is pattern for this concept from Thoughtworks named as ObjectMother

Pitfalls of Development Driven Testing -- TDD

There comes a time during battles when elite commandos have to throw away their best gadgets which may include sophisticated gears, body armors, tools and weapons and resort to hand-to-hand combat. During one of those moments, I wrote the following blog post
Confessions of a failed extreme programmer

After the fog of war was over, I was told by my colleagues about the bugs in my components in certain scenarios. These bugs would have been never there, if only I had written my unit tests. So I started writing my tests using the framework which I prepared.
To me surprise, my test was succeeding while in real condition, it should have failed. After serious debugging, I found a serious bug in my framework and as a result, 40% of my automated tests were flawed.


Well, if you survived your hand-to-hand combat, you have to oil your gear.

Moral of the story: It does not hurt to use a knife during hand-to-hand combat. Not using it may prove to be fatal. Automated Unit tests are knives to Developers locked in a mortal combat with very aggressive deadlines.

Integrating MStests with Nant

Intgrating MSTests with Nant

MSTest.exe is command line utility which can be executed using Exec Task of Nant

MSTest Command Line Options
http://msdn2.microsoft.com/en-us/library/ms182489.aspx


BeginTag exec
program ="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe" commandline="/testcontainer:C:\Projects\ProjectName\Build\WebTests\Matrix.WebApplication.Tests.dll /resultsfile:C:\Projects\ProjectName\Build\WebTests\a.trx" basedir="C:\Projects\ProjectName\Build\WebTests" >
EndTag exec

testcontainer: Load a file that contains tests
runconfig: Load a file that contains tests
resultsfile: Save the test run results to the specified file


CruiseControl and MSTests


http://confluence.public.thoughtworks.org/display/CCNET/Using+CruiseControl.NET+with+MSTest
http://blogs.blackmarble.co.uk/blogs/bm-bloggers/archive/2006/06/14/5255.aspx



Running Unit Test on Build Server
In order to run tests during build, Team Edition for Testers must be installed on the build computer. In order to run unit testing, code coverage or code analysis, Team Edition for Developers must be installed on the build computer.

http://msdn2.microsoft.com/en-us/library/ms181712.aspx

Converting NUnit Tests to MSTest

I have been deliberating for some time whether to stick with NUnit or go for MSTest.
http://vikasnetdev.blogspot.com/2006/07/eight-point-checks-for-servicing.html

Advantages of MSTest over NUnit
1. Excellent IDE Integration
2. Code Generation
3. New Attributes
4. Enhancements to the Assert class
5. Built-in Support for testing non-public memembers.

After hearing from the colleague that debugging NUnit tests is not working great with Visual Studio 2005, I decided to plunge into MSTest. First step is figure out how move previous NUnit tests to MSTest. Here are steps

Step 1: Start with James NewKirk’s blog post

Step 2: Download the NUnit Converter V1.0 RC1 from workspace


Step 3: Install the Guidance Automation Extensions & Toolkits from link


Step 4:Double-click the file: “NUnit Converter.msi” to install the converter. One caveat: It has not been tested in any other directory than the default directory. This of course does not mean it will not work in a different directory it just means that it might not. Also the rest of the instructions assume you have put it in the default directory. You can think of this as a strong hint to leave it in the default directory.

Step 5: Start Visual Studio 2005 Team System.
Step 6: Open a solution file that has existing NUnit test code.
On the Tools menu, click Guidance Package Manager. A dialog box should open, see below. You should check to make sure that the “Convert NUnit Test Code” Recipe is present. Then click Close.





Step 7: You have completed the installation.


Step 8: Back-up the files and their associated project and solution files. This step is critically important. There is no automated restore of your files back to a previous state.

Step 9:Start Visual Studio 2005 Team System.
On the File menu, navigate to Open, click Project/Solution. Navigate to the directory where the Project/Solution is contained and then select the file you wish to open.
On the File menu, navigate to New, click Project. Select the appropriate (C# or VB.NET) test project and place it in the directory of your choosing. See “Tests must be in a Test Project” below.
Copy each file that contains NUnit test code that you want to be converted into the test project.
Add any required references (including a reference to NUnit) and compile the test project. Once the code compiles, run the tests in NUnit to ensure that you are starting with a working test harness. This step is optional but I like to do it because if the conversion process introduces problems, I know that I started with a working baseline.
Step 10: Now onto the conversion process. Right-Click the test project that you created in previous step in the Solution Explorer. Click the Convert NUnit Test Code. As each file is being converted it will be opened in Visual Studio. When the conversion is complete, the conversion results will be displayed.
Once you have completed the conversion process you should disable the guidance package. The reason is that every time you right-click in the Solution View the guidance package looks for NUnit test code. If there isn’t any to find it just wastes time. On the Tools menu, click Guidance Package Manager. A dialog box should open. Click Enable/Disable Packages. You should uncheck “NUnit Test Code Conversion”. Then click OK.

RowFixture Example in C# -- Fit

EmployeePayRecordsRowFixture.cs
using System;


public class EmployeePayRecordsRowFixture : fit.RowFixture
{
public override Object[] Query()
{

EmployeePayRecord[] records = new EmployeePayRecord[2];
records[0] = new EmployeePayRecord(1, 1000);
records[1] = new EmployeePayRecord(2,2000);
return records;
}

public override System.Type GetTargetClass()
{
return typeof(EmployeePayRecord);
}
}


EmployeePayRecord.Cs
using System;
public class EmployeePayRecord
{
public int id;
private double salary;
public EmployeePayRecord(int id, double salary)
{
this.id = id;
this.salary = salary;
}
public double pay()
{
return salary;
}
}