Md. Adil Akhter's Weblogs

More on Unit Testing : TestContext

In Test Driven Development  as a developer we spend significant amount of time in writing unit tests. As improving coding coverage, testing all the boundary condition and ensuring the of quality code is significantly important, writing unit test effectively become one of the priority that we has to consider in software development.

In our today's discussion, we will see what is TestContext of VSTS unit testing framework and how we can use TestContext  to leverage writing effective unit tests for our application.

Prior to move forward with our today's Discussion on TestContext, I would really suggest you the following postings-

• Why unit testing is so important?

• Test Driven Development in a Nutshell.

So, let's begin with a brief description on what is TestContext. Then we will go through different scenarios where we can use TestContext. :)

What is TestContext?

TestContext is a abstract class of Microsoft.VisualStudio.TestTools.UnitTesting namespace that provides various information about the current test run. Purposes that has been served by TestContext Class -

1.  To store information and provide information to the unit tests during Unit Test Run.

2.  Provide a mechanism to measure performance of your code being tested by the Unit Test.

3.  In Testing the web service it stores the additional information, like server's URL.

4.  In Asp.Net unit tests, it get holds of the Page object.

5.  For Data Driven Unit Tests , it provides access to the data rows.

The class definition of the TestContext Class -

   1: public abstract class TestContext

   2:    {

   3:        public const string AspNetDevelopmentServerPrefix = "AspNetDevelopmentServer.";

   4:  

   5:        protected TestContext();

   6:  

   7:        public virtual UnitTestOutcome CurrentTestOutcome { get; }

   8:        public abstract DbConnection DataConnection { get; }

   9:        public abstract DataRow DataRow { get; }

  10:        public abstract IDictionary Properties { get; }

  11:        public virtual System.Web.UI.Page RequestedPage { get; }

  12:        public virtual string TestDeploymentDir { get; }

  13:        public virtual string TestDir { get; }

  14:        public virtual string TestLogsDir { get; }

  15:        public virtual string TestName { get; }

  16:  

  17:        public abstract void AddResultFile(string fileName);

  18:        public abstract void BeginTimer(string timerName);

  19:        public abstract void EndTimer(string timerName);

  20:        public abstract void WriteLine(string format, params object[] args);

  21:    }

To start with the TestContext , we need to add a property in our Unit Test class as -

  
Figure1: TestContext Property in Unit Test class

Now if we just add a simple test and debug it - we will find that the VSTS Unit Testing Framework actually using an instance of  UnitTestAdapterContext which is derived from TestContext. This property TestContext is automatically initialized/assigned by the test run engine of VSTS when the Unit Test class is initialized after [ClassInitalize] method and before [TestInitalize] method.

  Figure2 : UnitTestAdapterContext and its' properties in Debug Mode

Want to know more about TestContext?

It would be really hard to find the assembly  that contains UnitTestAdapterContext Class unless we search the private assemblies installed in <vs installation directory>\common7\IDE\PrivateAssemblies ; in my case which is - C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies.The assembly that contains UnitTestAppterContextClass -Microsoft.VisualStudio.QualityTools.Tips.UnitTest.Adapter.dll.

UnitTestAdapterContext class looks like following in reflector -

Figure3 : UnitTestAdapterContext in Reflector

How can we use TestContext ?

Like I mentioned in the beginning , we can use TestContext in different cases writing unit tests. Now , we are going to look at some features of TestContext class that we can use very easily in our unit tests.

Scenario 1 : Getting path of the folder that current test run created for storing input and outputs

It's a really handy feature of TestContext. It provides you the path of the unique folder for current test run that VSTS unit testing framework creates in every test run. In VSTS unit testing framework, every test run create a unique folder in  machine where it's running the test and generate a xml based test report ( *.trx) -

Figure 4 : Folders/Directories that are created by Test Run

Additional input or output of unit test can be stored in this folder and also can be cleaned up before exiting the unit test(if required). Furthermore, it's the safest place to put the additional stuff related to unit tests because our application have full access to this folder ( just consider the situation where unit tests are running in a Build Machine or in a remote server where application might not have access to "C:\Temp\" folder :) ).

So, how can we get the path of the folder of current test run? Simple -

string testDirectory = TestContext.TestDir;

We can get access to the deployment folder  and the folder that contain logs  as well -

string deploymentDirectory = TestContext.TestDeploymentDir;
string logDirectory = TestContext.TestLogsDir;

Scenario 2 : Generating report how much time was elapsed to complete the Unit Tests

TestContext Class has 2 public member BeginTimer and EndTimer which takes a string parameter as argument ( Name of the timer). Using this feature of TestContext class, how much time elapsed to run particular unit test can be measured very easily. This feature of TestContext might be useful in tracking how much time the code to be tested is consuming and whether or not it's going to meet speed criteria of nonfunctional requirements.

   1:  TestContext.BeginTimer("longRunningProcess");

   2:   

   3:  // Call the long running method here to test whether it meet the performance requirement

   4:  //....

   5:  //

   6:   

   7:  TestContext.EndTimer("longRunningProcess");

   8:            

Result of the timer is shown as -

Figure 5: Output from the Timer

Scenario 3 : Adding additional information in Test Result

There is another cool property in the TestContext class which gives you flexibility to provide additional information in Test Result which will be stored in Test Result file( .trx extension stored as Xml). This could be really useful to provide additional information about the Test such as Test Environment, parameter and other details that might be important to store with test result. Lets consider a particular unit test -

   1: [TestMethod]

   2: public void ShouldCreateUser()

   3: {

   4:     // ... Unit Test Codes....

   5: }

   6:  

   7: [TestCleanup]

   8: public void TestCleanup()

   9: {

  10:     TestContext.WriteLine("{0} : {1}", TestContext.TestName ,TestContext.CurrentTestOutcome);

  11: }

Using TestContext.WriteLine , we can provide additional information [ For Example - just to show, in the above example at line 10 , we are writing the test name and test result] and that is visible to the test result viewer as -

Figure 6: Output from TestContext.WriteLine


Scenario 4 : TestContext in Asp.Net Unit Testing

TestContext provides the access to the Asp.net Page object representing the current web request while unit testing Asp.net Web Application. How? TestContext has a property - RequestPage which is actually an instance of System.Web.UI.Page object and defined as-

"...references the Page object created by the URL used to invoke the test"

Figure 7: TestContext.RequestPage

This property is only valid for Asp.Net Unit Testing. After getting hold of Page Object of current web request, any control of the page can be accessed using FindControl method of the Page Object. Using PrivateObject class, we can invoke the private/protected methods of the current .Aspx page represented by Page Object.

Example of an Asp.net Unit Test :

   1: [TestMethod]

   2: [HostType("Asp.Net")]

   3: [UrlToTest("http://localhost/ourwebapplication")]

   4: public void TestMethod()

   5: {

   6:     Page page = TestContext.RequestedPage;

   7:  

   8:     PrivateObject privateObject = new PrivateObject(page);

   9:     

  10:     Button button = (Button)page.FindControl("Button1");

  11:     privateObject.Invoke("Button1_Click", button, EventArgs.Empty);

  12:  

  13:     Label label = (Label)page.FindControl("Label1");

  14:  

  15:     Assert.AreEqual<string>("Hello World !!!!", label.Text);

  16: }

So, first we get hold of our Page object(Line 6) representing our current web request(UrlToTest in Line 3) through the TestContext.RequestPage which eventually enable us to access any control of the page object(e.g. Line 10 & 13). Using the PrivateObject( line 8), we could conveniently invoke any member of the page class as well (line 11).

Hence, using TestContext, we can effective leverage our codes inside Aspx page into Test5 Coverage.

Scenario 5: TestContext in Data Driven Unit Tests

In Data Driven Unit Test, TestContext provides access to the current DataRow for which test is running and by that way, it provides access to every DataRow of the DataSource one by one.

In the following example, we will see how the TestContext enable us to getting access to every DataRow in the DataSource -

First, lets define our Table that contains few UserContacts with valid information. So, our unit test should create every one as a UserContact of our Application. But that's not our example's goal here. In this example , We will see how TestContext enables us to access every UserContact stored in the UserContact Table so easily.

Figure 7: UserContact Table Definition

Let's put some Valid User Contact Information in our Table - UserContact -

Figure 7: Data in UserContact Table

After that, let's write our unit test -

   1: [DataSource("System.Data.SqlClient", "[path to MDF]\";

   2: Integrated Security=True;User Instance=True", "UserContact", 

   3: DataAccessMethod.Sequential), TestMethod()]

   4: public void ShouldCreateUsers()

   5: { 

   6:     string userLoginName = (TestContext.DataRow["LoginName"].ToString());

   7:     string userFirstName = (TestContext.DataRow["FirstName"].ToString());

   8:     string userLastName = (TestContext.DataRow["LastName"].ToString());

   9:     string userEmailAddress = (TestContext.DataRow["EmailAddress"].ToString());

  10:     string userDepartment = (TestContext.DataRow["Department"].ToString());

  11:  

  12:     TestContext.WriteLine("Creating user - Login Name :{0} Name : {1} {2} 

  13:                           EmailAddress : {3} ", userLoginName, userFirstName, 

  14:                           userLastName, userEmailAddress);

  15:  

  16:     bool successful = UserManger.CreateUser(userLoginName, 

  17:                                           userFirstName, userLastName, 

  18:                                           userEmailAddress, userDepartment);

  19:  

  20:     Assert.IsTrue(successful);

  21: }

Scenario 6: TestContext.AddResultFile

Last but not the least, TestContext has another useful member called AddResultFile which is defined as -

void AddResultFile(string filename)

Through TestContext.AddResulFile, additional files can be added with the test result. The additional file will be stored in the unique folder created for current test run.This might be useful in some cases, for example, if we are validating our objects with some external resource, like schema - we can store the schema with our test result so that we can validate our test result later on after test run.

Conclusion

Hence, we can utilize the TestContext class in several cases to solve our problem in writing unit tests. But saying all this, I would like to emphasize on designing test cases and map it to a unit test carefully because "Harnessing the power that is provided by the tool and utilizing it effectively and every possible way" could only bring desirable result .

In our today's discussion, we went through several scenarios where we can leverage TestContext to write a better and precisely more effective unit test using the Unit Testing Framework provided with Visual Studio. Thanks for being with me so far and I would really appreciate comments or any suggestion.

I would really appreciate any comments or suggestion on this topic.  

Passing Parameter to a Predicate in .Net2.0

In this post, we will see how to pass parameter to a method representing Predicate.

Let's say, we have a collection of SprintBacklogItem and we want to filter all the SprintBacklogItem with Title start's with, let say "QA" or "Dev Task" depending on a input parameter. Now from the previous post we know that , predicate only have 1 parameter of type T.

Then, how to pass a input parameter _HeaderToSearch in Predicate?

1. To do that, we need to a new object called ListMatcher -

public class ListMatcher 
   { 
       private string _HeaderToSearch; 
       public ListMatcher(string headerToSearch) 
       { 
           _HeaderToSearch = headerToSearch; 
       }  

       public bool Predicate(SprintBacklogItem item) 
       { 
           return item.Title.StartsWith(_HeaderToSearch, StringComparison.InvariantCultureIgnoreCase); 
       }  

   }  

2. Next , I initialized the ListMatcher object and use the HeaderToSearch  to filter the items-

ListMatcher matcher = new ListMatcher("QA"); 
this.FindAll(matcher.Predicate);

Done.:)

TDD - In a Nutshell

"One Picture's  Worth Thousands Words"

And so on...

Why Unit Testing is so important?

Why writing unit tests are so important - lets consider a development team developing a module( call it - [A])did not consider the unit testing that seriously. What happens to that module -

1. [A] produced lot of Bugs in the development phase since it was not tested adequately. And while fixing it- [A] produced severe impact on other modules too because integration was failing again and again. So, the dependent module had to change as well to stabilize whole Delivery.

2. That's not the end of misery. In the release testing, huge amount of bugs identified which also produced from the uncertain behavior of [A]  and fixing those become a hell of a job for the developers. Just to show you one old basic diagram of software development life cycle -

3. After the deliverable delivered to the client - Developers could not take pride for that because they were not confident whether they delivered a Good Product( from a developers perspective, I think its really crucial to deliver something from which you can take pride).

4. [A] became more susceptible and fragile day by day. And developers become really reluctant and was not comfortable to change the codes for any change request because of the code's inherent fragility.

5. Refactoring become very error-prone and troublesome.

So, after some time - Developers started calling [A] as "Dead Zone" or Legacy Code because [A] become quite impossible to manage.

Now if we go back to the days when the developers were planing or starting the development process using our Time Traveler- what would you advise them?  :)

The situation that I just described,  its not new to most of the developers developing for a long time. That's why some intelligent people in agile world sit together and come up with some basic rules and practices that we must follow to make our product worth taking pride. One of them is writing Unit Tests for your codes considering all the test criteria considering -

1. Unit Tests are the first users of your Unit who ensure that your own Creation  is working that way you wanted to. Remember - "Taking pride". It become much easier to achieve.In addition, Learning Curve become much higher -because, you get to know very explicitly what are the cases you missed while writing unit tests initially that produce bugs. That way it makes you much mature developer day by day.

2. Unit Tests are the living description how the Unit should work. Any one new to your unit as a developer , should just need some time to go through the Unit Tests to get the Idea how the unit should work.

3. Unit Tests are the tools that make integration much easier.

4.Last but not that least - Refactoring was never been so much easier if there were Unit Tests.

Any comments or suggestions on this post is most welcome.

Using Predicate & Action of .Net2.0

While I started developing software, I faced this situation over and over again where I had to iterate thorough the whole collection and perform some action on each of the element of the collection or filter elements depending on some logic. It was really annoying to  write same for/foreach loop again and again.

.Net framework2.0 resolve this issue where we can just tell the collection how to filter / how to perform some action on each element of the collection and it take care of the iteration part.  Let's check out the List<T> Class of System.Collections.Generic and what support it provides -

Huge support for Searching, Sorting and Filtering!!! If we look at the declaration of let's say - FindAll and ForEach  -

public List<T> FindAll(Predicate<T> match);public void ForEach(Action<T> action);

Here Predicate and Actor are the generic delegate which gives us the flexibility to provide a way to filter the collection or perform action to each and every element of the List. Let's dig deeper inside them -

Inside Predicate:

Predicate is a Generic Delegate which takes support from the new generic feature of .Net Framework2.0. It is defined -

delegate bool Predicate<T>(T obj)

As per definition of MSDN, Predicate -

"represents a method that defines a set of criteria and determines whether the specific object meets this criteria."

In short, Predicate is just a generic delegate that takes T as object and check whether the object fulfill some criteria and depending on that return true|false.

Example

In this example, by using Predicate, we are going to tell the Collection how to filter and Collection will handle the whole iteration and filtering process -

Let's say, we have a collection of SprintBacklogItem and we want to filter them depending on there State == Closed, we can do it using predicate -

1. Define a method that represents the Predicate -

private bool HasStateClosed(SprintBacklogItem item) 
        { 
            if (item.State == SprintBackLogStatesStrings.CLOSED) 
                return true; 
            return false; 
        }

This method simply checks whether the SprintBacklogItem's state is closed or not and depending on that , return true or false. Now, if we look at the declaration of the method , we are affirmative that we can use Predicate to represent this method.

2.  Following line of code filters all the closed SprintBacklogItems -

List<SprintBacklogItem> closedItems= _SprintBackLogsItems.FindAll(HasStateClosed);

Inside Action:

Similar to Predicate,

"Action is also one kind of generic delegate which represents a method that take the object as input and perform some operation on that."

Definition of Action delegate-

delegate void Action<T>(T obj);

From the signature of the delegate, it can represent the method with signature that must have one parameter passed to it and void as return type.

In List<T> , the method represented by the Action delegate takes an input obj and perform actions on that.

Example

In this example, by using Action, we are going to perform some predefined actions( initializing ActualHour = 10) on each elements of the List -

1. Define the method that will be represented by Action -

public void InitActualHour(SprintBacklogItem item) 
        { 
            item.ActualHour = 10; 
        }

2. Following line of code initialize all the elements' Actual hour to 10 of the List -

this.ForEach(InitActualHour);

Isn't it pretty cool and slick ? Instead of implementing methods for Actor and Predicate , we could have used Anonymous Delegate. I will cover that topic in my future posts. Bye for now. :)

Designing Efficient Immutable .Net2.0 Objects

What is an immutable object?

By definition immutable object is the object whose state can not be changed after it is created. That means, after creating the object, its publicly exposed members can not be changed from their initial assigned values. On the contrary, mutable objects are objects whose state can be changed at any point of time.

Every developer has to take a important decision whether to make a class mutable or immutable while designing the domain model.
While taking this decision, careful considerations can make us avoid the potential pitfall of using immutable object.   Why & How using immutable .Net object – is our today’s discussion. Let’s begin with How part . 

How to implement .Net Immutable Object?

 The way I would implement an immutable .Net class –           

-          Make the fields private readonly.
-          Provide a Public property with get accessor.
-          If the class is no longer needed to inherited – making it sealed. 

Like in the following example, I am implementing an immutable class  UserContact which will be inherited in User – 

 Here is the Implementation of the Immutable classes –     

    public class UserContact

    {

        private readonly string _Name;

        public string Name   

        {

            get { return _Name; }

        }

        private readonly string _EmailAddress;

        public string EmailAddress

        {

            get { return _EmailAddress; }

        }

        public UserContact( string name , string emailAddress)

        {

            _EmailAddress = emailAddress;

            _Name = name;

        }

    }

UserContact get inherited by User as follows [Since User class is no longer inherited – we make it sealed] -

    public sealed class User : UserContact

    {

        private readonly string _UserName;

        public string UserName

        {

            get { return _UserName; }

        }

        public User(string name, string email, string userName)

            : base(name, email) { }

    }

So, isn’t it really easy to implement a Truly Immutable class in .Net framework? J Now the question pops into our mind – why we will be using immutable .net objects , what would be benefits of that ? Let’s explore that –  

Why use immutable object?

 Protection:

From the definition we know, Immutable objects can not be changed after its being initialized. So, while using inside application, immutable object can flow in different layers of the application without getting worried about being altered by different layers.  

Performance:

Copying object will be much easier, we just need to copy the reference instead of copying the whole object. It would be much faster to copy reference than the whole object.

User user = new User("adil", "adil.bd@hotmail.com", "adak");
User userTemp = user; 

In case of mutable object, we would need to create defensive copy of the object and in .Net term, we need to create a Deep Copy of object otherwise, changing a property in the actual mutable object would reflect everywhere where the object is referenced. For example, let’s consider User as mutable; then changing any thing in user object will have same impact on userTemp as well which is not intended.

To avoid this situation, in case of mutable object, we need to make a Deep Copy of the object which is a costly operation. However, for immutable object, copying the reference would be enough since its state can’t be changed. 

Scalability:

Thread synchronization is an issue of concern while designing multithreaded application. Overhead of synchronizing immutable object is far less than mutable object. By default , an individual immutable object does not need to be synchronized as its state will be not be modified by any thread. However, since the immutable object will still be accessed thorough reference , it would require some synchronization. In complex sync scenarios, immutable object would perform far better then mutable version.   

Consistency: 

If we consider inheritance hierarchy, immutability provides a way for the sub-class to maintain consistency in inheritance hierarchy. Consider following mutable objects–