Team System Unit Test and Output Directories

I always use NUnit to write my unit tests but now at Intergen I also use Microsoft Visual Studio Team System Unit Tests. Today I was stuck by a very basic problem and here it is.

I have a XML file in my project which is added to the output directory when compiled.

When I was running my unit tests against this, Visual Studio threw me this error saying that it couldn’t find the file!

(click to enlarge)

I was really surprised as my XML file is said to copy to output directory and the test fails saying that there is no such file. Checked my Test Solution’s output directory and found that there is indeed the Templates folder and the XML file.

So, whats the problem? Why is my test failing?

Well, the VSTE has a separate directory where it stores all its test results. The directory can be found in your root directory of your solution under the name TestResults. The TestResults also have various folders for each test run you do. If you refer back to the error image that is attached above, you could get the exact directory name. So, the VSTE did not copy the Templates directory to this ‘dynamic’ (for each test run there will be a directory created : correct me if am wrong here) directory. How do we do this then?

The answer is with the Local Test Run Config’s Deployment settings. You can find the local test run config in your solution browser.

Double click the file to open the properties dialog and go to the Deployment section.

Specifying a file or directory here would be included along with the test results 🙂

My test doesnt fail now 8)

Another way to do this (if its a single file : if you know how to add for a directory, please do leave your comment 🙂 ) is to specify along with your test method,

[TestMethod, DeploymentItem(@”Templates\BirthInputTemplate.xml”)]

public void Test_BuildInputXML()
{
}

Mocking Events [With RhinoMocks]

Suppose we have an Inerface called IFooDatabase . Think this Interface as our gateway which will provide us with basic database operations.

Now, how does Mocking come here? – My friend is still working on this database layer but he has given me already the Interface with which he is implementing the Database Class, so that I can make use of that and mock, as if that database layer exists and test my program against it.

What mocking framework I am using? – RhinoMocks

My friend told me that he is going to add events for each database operation, like InsertEvent, UpdateEvent, DeleteEvent so that they may be raised for each insertion, updation and deletion operations respectively.

For this post, to make it simple, let me take just the InsertEvent. Here is the class diagram,

And here is my Class which is going to make use of this Interface

I was pretty happy that my friend provided me an Interface to mock all the database activities, but I was really stuck on how do I test all those Events are raised!

Well, been using one of the best Mocking Frameworks around, RhinoMocks did provided a way to mock Events 😉

So, here is my test case,

[Test]

public void TestInsertEventRaised()

{

MockRepository fooDatabaseMock = new
MockRepository();

IFooDatabase

   fooDatabase = fooDatabaseMock.DynamicMock<IFooDatabase>();

fooDatabase.FooDatabaseInsertEvent += null;

LastCall.IgnoreArguments();

IEventRaiser
fooEventRaiser = LastCall.GetEventRaiser();

fooDatabaseMock.ReplayAll();

Foo myFoo = new
Foo(fooDatabase);

fooEventRaiser.Raise(this, EventArgs.Empty);

Assert.IsTrue(myFoo.InsertEventRaised);

}

RhinoMocks provides an interface called IEventRaiser which you can use to raise events!

Here is what we are doing,

• I am assigning null to the EventHandler and telling RhinoMocks that please do ignore the arguments in my last call. This helps us because we may associate our event to any Event Handler with different event arguments
• We initialize IEventRaiser by getting the last event, which in our case is FooDatabaseInsertEvent
• We pass on the Database object which is mocked to my Foo class to use
• And finally we raise that last event
• And do a simple Boolean check to see actually we did raise the event

Wasn’t that easy 😉

You may complain that I have used the generalized EventArgs and completed this post. What about custom EventArgs?

No worries, that also takes the same route 😉

[Test]

public void TestUpdateEventRaised()

{

MockRepository fooDatabaseMock = new
MockRepository();

IFooDatabase

  fooDatabase = fooDatabaseMock.DynamicMock<IFooDatabase>();

fooDatabase.FooDatabaseUpdateEvent += null;

LastCall.IgnoreArguments();

IEventRaiser fooEventRaiser = LastCall.GetEventRaiser();

fooDatabaseMock.ReplayAll();

Foo myFoo = new
Foo(fooDatabase);

fooEventRaiser.Raise(this, new
FooDatabaseEventArgs(“datbase”,true));

Assert.IsTrue(myFoo.UpdateEventRaised);

}

The FooDatabaseEventArgs is our custom EventArgs.

I would recommend anyone reading this post to try out the sample posted below if you really want to understand what is happening 😉

You can download the sample here

Revisiting Mock Objects

My last post on Mock Objects explained briefly about what is Mocking and gave you an example. But that example is not explained and thought let me explain and how Mocking plays its part here.

So, revisiting that example,

[TestFixture]
public class AdminTests
{
    private MockRepository mocks;
    private EduAdmin eduAdmin;
    private Bl.IBLAdmin mockAdmin;
    private delegate bool ValidRegisterDelegate(Db.Admin entity);

    [SetUp]
    public void Setup()
    {
         mocks= new MockRepository();

         mockAdmin = mocks.DynamicMock<Bl.IBLAdmin>();
    }

    [Test]
    public void Check_Method_Register()
    {
        AdminEntity inputEntity = new AdminEntity();
        inputEntity.AdminId = “admin”;
        inputEntity.AdminPassword = “admin”;

        Db.Admin dbAdmin=new Educator.DataAccess.Admin
        {
            AdminId = “admin”,
            AdminPwd = “admin”
        };

        With.Mocks(mocks).Expecting(() =>
        {
            Expect
                .Call(mockAdmin.Translate(inputEntity))
                .Return(dbAdmin);

            Expect
                .Call(delegate { mockAdmin.Insert(dbAdmin); })
                .Callback((ValidRegisterDelegate)
                               ((entity) => { return entity.AdminId == “admin” && entity.AdminPwd == “admin”; }));

        }).Verify(delegate
       {
           eduAdmin = new EduAdmin(mockAdmin);

           eduAdmin.RegisterAdmin(inputEntity);
       });
    }
}

To explain the above example, consider this diagram

(Please consider the line separation, I will come to it later, Ignore the Tests)

So, as the diagram explains, we have,

1) EduAdmin which is our Service Layer (SL)

2) IBLAdmin which is our Business Layer (BL) Interface, and,

3) Database Layer (DL)

The BL interacts with DL to perform database operations and SL sends requests to BL in regard to what needs to be done.

So, what does the above example test function do? Here it is,

Revisiting again the definition of Unit Testing,

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application.

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy.

So, testing this RegisterAdmin function involves the use of BL as well DL (via the BL). And also from the first diagram, we do show that each layer is tested against their own tests. So, using Mock Objects, now we come down to,

Since we have mocked our BL, we can now write expectations on how it has to behave and what results it has to give for our Service Layer to work properly 🙂

To dig deep, we may have something like this,

Admin is a class that implements our Interface IBLAdmin and AdminEntity is business type and DB.Admin is a database type.With Mocking, we don’t care about the Class but the Interface. EduAdmin is our Service Layer class and it has a function RegisterAdmin

So, to RegisterAdmin function to work properly, we have to see that the BL’s Translate and Insert functions return proper results and those are nothing but setting expectations on our mock object which is IBLAdmin 8) . If you think slowly where we are, you will probably get what is Mocking 😉

Here is that part which sets expectations and tells what should be returned respectively

        With.Mocks(mocks).Expecting(() =>
        {
            Expect
                .Call(mockAdmin.Translate(inputEntity))
                .Return(dbAdmin);

            Expect
                .Call(delegate { mockAdmin.Insert(dbAdmin); })
                .Callback((ValidRegisterDelegate)
                               ((entity) => { return entity.AdminId == “admin” && entity.AdminPwd == “admin”; }));

        }).Verify(delegate
       {
           eduAdmin = new EduAdmin(mockAdmin);

           eduAdmin.RegisterAdmin(inputEntity);
       });

What does that ValidRegisterDelegate do? It checks whether the input parameters that is being used to invoke Insert function is of expected type and has expected values. Its more of a RhinoMocks feature, so once you start using it, you will get used to it 😀 . And RhinoMocks follows the Record and ReplayAll method where we set expectations means that we record something and once we say to verify, it replays all the set expectations when invoked.

The expectations we set are very simple. When the Translate function is called with an input parameter of type AdminEntity, return an object of type Db.Admin . Similarly for Insert function, except that we don’t return anything.

In the Verify stage, we can see that we create a new instance of our SL by passing the BL Interface object. What are we doing here? Welcome to the world of Dependency Injection 😀 . We explicitly tell that – “Hey, here is my BL object which you have to use and please use this“. We inject dependency here! So, now the BL object is already in the MockRepository and when we tell our SL to use this object, it means that its going to use the MockRepository object with expectations set on it 8)

I think now things are getting clear and you should be able to understand this diagram way better than earlier 🙂 (which is also shown above)

Coming back to Dependency Injection – You may be wondering that so if my client uses this SL, will he always have to explicitly tell that this is my BL and use it? – NO. The way we overcome is using multiple constructors 🙂

public class EduAdmin
{
     private IBLAdmin blAdmin;

     public EduAdmin(IBLAdmin mockAdmin)
     { blAdmin=mockAdmin;}

      public EduAdmin() : this(new Admin())
     { }
}

I think thats self explanatory on what we do 😉

Hope this explained how we Mock 8)

If you have any doubts, please do leave your comments and I will try to answer them 🙂

Mock Objects

So, you have started reading or doing more on Test Driven Development? Then am sure you would have now heard about Mocking or Mock Objects 😀

Before getting started and seeing what is this Mock Object, let me quote the definition of Unit Test from Wikipedia

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application.

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy.

So, Unit Testing covers testing each individual part in your program. In other words, when we say we are unit testing a Component A, we actually test the functions, properties etc., inside that component.

Below is a pictorial representation of what we do,

For Component A , we write several unit test cases and test it. Since this component does not depend on anything else, it is fairly easy to test all the parts of the component and hence it satisfies the definition of Unit Testing.

Now we bring in another Component B, which depends on Component A and thus now we have something like this,

How do we test Component B now?

Let me write down the scenario of where we are now,

1) We have Component A which is been tested

2) We have Component B which uses/depends on some of the functions of Component A

3) We have to test Component B such a way that its isolated from Component A, yet still use Component A

4) If we test along with Component A with Component B, its not Unit Test, rather its, Integration Testing!

What do we do now? Mock Component A 8)

Yes, here comes the use of Mock Objects. From Wikipedia,

In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to test the behavior of a car during an accident.

So, its kinda Fake Object, but a Mock Object has some expectations and results being set on it.

Now, to make use of Mock Objects, we change the Component A to implement an interface Interface A and Component B an interface Interface B .Using Interfaces helps us to have just the functions and properties of the Component being written which is what Mock needs 😉

Here we are now,

TDD has hence allowed to make changes to your design now and you would have changed tests accordingly.

Introducing Mock Objects, we now have,

So, we interact with Component A using our Mock Repository which holds the Mock Object – Interface A

We can now set expectations on Mock Objects, meaning that, you can say that – When a function named FunctionA is called, return the string “Hello World”

It may confuse you initially, but am sure you will get the whole picture once you start mocking yourself 😉

Here is a sample test case along with Mocking (Using NUnit and Rhino Mocks),

[TestFixture]
public class AdminTests
{
    private MockRepository mocks;
    private EduAdmin eduAdmin;
    private Bl.IBLAdmin mockAdmin;
    private delegate bool ValidRegisterDelegate(Db.Admin entity);

    [SetUp]
    public void Setup()
    {
         mocks= new MockRepository();

         mockAdmin = mocks.DynamicMock<Bl.IBLAdmin>();
    }

    [Test]
    public void Check_Method_Register()
    {
        AdminEntity inputEntity = new AdminEntity();
        inputEntity.AdminId = "admin";
        inputEntity.AdminPassword = "admin";

        Db.Admin dbAdmin=new Educator.DataAccess.Admin
        {
            AdminId = "admin",
            AdminPwd = "admin"
        };

        With.Mocks(mocks).Expecting(() =>
        {
            Expect
                .Call(mockAdmin.Translate(inputEntity))
                .Return(dbAdmin);

            Expect
                .Call(delegate { mockAdmin.Insert(dbAdmin); })
                .Callback((ValidRegisterDelegate)
                               ((entity) => { return entity.AdminId == "admin" && entity.AdminPwd == "admin"; }));

        }).Verify(delegate
       {
           eduAdmin = new EduAdmin(mockAdmin);

           eduAdmin.RegisterAdmin(inputEntity);
       });
    }
}

More resources on Mock Objects,

1) All about Mock Objects

2) Mock aren’t Stubs

3) Rhino Mocks

Unit Testing the Database Access Layer

Its been fun after getting into Test Driven Development 🙂

What I do is, test each individual components, layers in my project before its being used by other components and layers. So, currently am testing the Database Access Layer (DAL). Testing DAL is more tricky and many people follow different methods.

1) Many follow a Repository Pattern to test the DAL

2) Many use a in-memory database to test the DAL

3) Many use development database to test the DAL

4) Many use live database to test the DAL

So, which is best? – That really depends on your interest. For the Repository Pattern and in-memory database you may need to write a full length code which does similar job as your DAL, and that requires some amount of your development time. Development database means that each developer will have access to a development database in his local machine or network server. This is also good because you test as what would happen in the real time. Live database is same as development database, except that you are in high risk as you are working against the live database!

What I have chosen? – Testing against a development database 😀

As I learn more about TDD, I will eventually shift to Repository Pattern

I ran into more problems of implementing the Repository Pattern as my DAL is LINQ-to-SQL and though there were few posts about how to unit-test LINQ-to-SQL layer, It was ending up doing more work for testing!

So, what I did was – I maintained my table data as Lists and passed on to DAL and tested against them.

1) I made my test data ready

private static List<Admin> expectedAdminList;

private void PrepareAdminTestData()
{
    expectedAdminList.Add(new Admin{AdminId = "admin",AdminPwd = "genius"});
}

The data that resides in my list is the data that is already present or in other words, the data which I have put in my development database.

2) So, now running a simple test to get the record count,

[Test]
public void Check_Property_AdminCount()
{
    int nExpected = expectedAdminList.Count;

    AdminContractor adminContract = new AdminContractor();

    int nResult = adminContract.AdminCount;

    Assert.That(nResult, Is.EqualTo(nExpected));
}

Its nothing but, checking against the count of my List 😉

3) What about Insert?

[Test]
public void Check_Method_InsertAdmin()
{
    expectedAdminList.Add(new Admin { AdminId = "chaks", AdminPwd = "chaks123" });

    Admin inputAdmin = expectedAdminList[(expectedAdminList.Count-1)];

    AdminContractor adminContract = new AdminContractor();

    adminContract.InsertAdmin(inputAdmin);

    Admin retAdmin = adminContract.GetAdmin(inputAdmin.AdminId);

    Assert.That(retAdmin.AdminId, Is.EqualTo(inputAdmin.AdminId));

    Assert.That(retAdmin.AdminPwd, Is.EqualTo(inputAdmin.AdminPwd));
}

Add to the list and then insert that new element. And now since your List which is holding the table data temporarily is updated, even the above test to count the number of records also passes, as we test the record count against the list count 🙂

Update and Delete also hold the similar way – Change the list, send to DAL

You have to keep one thing in mind when Deleting – you have to delete the item from the list too after being successfully removed from the database

Here it is,

[Test]
public void Check_Method_DeleteAdmin()
{
    bool blnExpected = true;
    Admin inputAdmin = expectedAdminList[(expectedAdminList.Count-1)];
    string inputAdminId = inputAdmin.AdminId;

    AdminContractor adminContract = new AdminContractor();

    adminContract.DeleteAdmin(inputAdminId);

    bool blnResult = adminContract.CheckAdminIdAvailability(inputAdminId);

    Assert.That(blnResult, Is.EqualTo(blnExpected));

    expectedAdminList.Remove(inputAdmin);
}

You can see that if the Assert passes,we delete that item from our list.

Remember one thing that if you want to run this test individually (of course we do want it 😀 ), use the [Setup] attribute (NUnit)

Here are my test results,

<Educator.Tests> (32 tests), [0:03.88] Success
  Educator.Tests.BusinessLogicTests (32 tests), [0:03.88] Success
    AdminContractTest (21 tests), [0:03.71] Success
      Check_AdminContract_Default_Contructor, [0:00.01] Success
      Check_Property_AdminCount, [0:01.99] Success
      Check_Method_GetAllAdmins, [0:00.14] Success
      Check_Method_GetAdmin_By_Id_Parameter, [0:00.32] Success
      Check_Method_GetAdmin_By_Name_Parameter_Exception, [0:00.03] Success
      Check_Method_InsertAdmin, [0:00.23] Success
      Check_Method_InsertAdmin_Exception, [0:00.15] Success
      Check_Method_UpdateAdmin, [0:00.10] Success
      Check_Method_CheckAdminIdAvailability_True, [0:00.01] Success
      Check_Method_CheckAdminIdAvailability_False, [0:00.00] Success
      Check_Method_DeleteAdmin, [0:00.03] Success
      Check_Property_DepartmentCount, [0:00.01] Success
      Check_Method_GetAllDepartments, [0:00.01] Success
      Check_Method_GetDepartment_By_Id_Parameter, [0:00.04] Success
      Check_Method_GetDepartment_By_GUID, [0:00.10] Success
      Check_Method_InsertDepartment, [0:00.04] Success
      Check_Method_InsertDepartment_Exception, [0:00.01] Success
      Check_Method_UpdateDepartment, [0:00.03] Success
      Check_Method_CheckDepartmentIdAvailability_True, [0:00.01] Success
      Check_Method_CheckDepartmentIdAvailability_False, [0:00.01] Success
      Check_Method_DeleteDepartment, [0:00.01] Success
    LoginContractTest (11 tests), [0:00.17] Success
      Check_LoginContractor_Default_Constructor, [0:00.01] Success
      Check_Method_CheckIdAvailability_Return_False, [0:00.03] Success
      Check_Method_CheckIdAvailability_Return_True, [0:00.00] Success
      Check_Property_UserCount, [0:00.00] Success
      Check_Method_GetAllUsers, [0:00.01] Success
      Check_Method_GetUser, [0:00.00] Success
      Check_Mthod_Login_True, [0:00.01] Success
      Check_Mthod_Login_False, [0:00.01] Success
      Check_Method_Register, [0:00.01] Success
      Check_Method_UpdateUser, [0:00.01] Success
      Check_Method_DeleteUser, [0:00.03] Success

I am sure this is not the best way, but it works for now 🙂

I am TDD :)

TDD isn’t really a new phrase. Its the acronym of Test Driven Development 🙂

I was introduced to TDD by my friend Ivan and now I firmly believe that TDD is the right development technique and practice that every developer should acquire.

Normally, we are taught the general development principle – “Design, Code, Test, Release (DCTR)” – This is the Model which most of the developers/companies follow. But with TDD it becomes – “Test, Code, Design“. What is the big difference here? Yes, there is. With the DCTR approach, your whole development process depends on the design and you strictly follow the design to release the product. The problem comes when there is a need to alter the design and change the code. It becomes very difficult here as your code and design are tightly coupled to each other. With TDD, you write tests for what your application has to do, which ultimately will lead you designing your application.

From Wikipedia,

Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.

Many now may have this feeling – “I am a Developer and why should I write test cases and test it! Let the Tester do it” – Its quite natural to get this feeling 🙂

But the TDD approach ensures that the code a developer writes is proper, well structured and BUG FREE. The only way to achieve this is to have Unit Test run on the code we write to see whether we are getting the right job done. If the tests fail, you can easily debug it and make it pass 😉

Here is an example (I am using NUnit for Test Framework)

– Lets say you want to write a function to add two numbers. It takes two integers and returns the result back to you.

With the TDD approach we first write a test for this

namespace SampleTests
{
    [TestFixture]
    public class SimpleTests
    {
        [Test]
        public void Check_Method_Add_Return_Result()
        {
            Test myTest = new Test();

            int nExpectedResult = 4;
            int nResult;

            nResult = myTest.Add(2, 2);

            Assert.That(nResult, Is.EqualTo(nExpectedResult));
        }
    }
}

It looks fairly simple, isn’t it :). There isn’t any magic going. I have an expected result and the result variable. I am going to call the Add function and get the result. If the expected result and the result which Add function gave are same, then it has added it properly 😉

So, now you go write your Add function and run the test case to see if your test succeeds

public class Test
{
    public int Add(int n1, int n2)
    {
        return (n1 + n2);
    }
}

This is very very simple example , but I do think its a good place to start. I would suggest writing small programs first and then slowly incorporate the TDD style in your projects.

Some of the tools (for .NET) you might need are,

1) NUnit

2) TestDriven.net

3) RhinoMocks

4) Resharper

And last but not the least, a good read at Martin Fowler’s articles 😉

In the coming days, I would go further into TDD