Category: Unit Testing

Musings on unit testing practices and efficiencies.

OnPropertyUpdate Schennanigans

The WPF application I’m working on at the moment has functionality to display multiple chart windows in a main application window page. The chart windows can be resized and moved around inside their window. I wanted to take the resizing and positioning behavior and abstract it so could apply it to other types of child windows besides just charts.

The application structure is based on an MVVM approach so this mean taking the positional pieces of a ‘ChartViewModel’ and abstracting them into a ‘PositionalViewModelBase’ that the ‘ChartViewModel’ and any other view models that would back views that are placed and manipulated on a page would inherit from.

To keep the view models agnostic to their views and to allow positioning change driven by business logic instead of just user interaction, the ‘INotifyPropertyChanged’ interfaced is implemented by the ‘PositionalViewModelBase’ type. What goofed me up was that I had to override the positional properties in the ‘ChartViewModel’ because the ‘ChartViewModel’ data is backed up by a persistence class specific to the ‘ChartViewModel’. I wanted to keep the ‘PropertyChanged’ event code in the base class though, so I came up with the below, using just width as an example:

//--base Positional class behavior.
 public virtual double Width
        {
            get { return this._Width; }
            set
            {
                this._Width = value;
                this.OnPropertyChanged("Width");
                SetParentDirty();
            }
        }


//--chart view model override
 public override double Width
        {
            get
            {
                return this.Model.Width;
            }
            set
            {
                base.Width = value;    //--What turned out to be the issue
                this.Model.Width = value;       
            }
        }

I set the property in the actual data class and the base, I do this so the base can handle setting the parent dirty and firing the changed event. However, I goofed. My chart windows were freaking out when I resized them. After investigating many conspiracy theories and trying to find ways to blame someone else, I realized my error. First I didn’t have any unit tests confirming the behavior, I just assumed it worked.

After adding a unit test I realized that when the property changed event was fired the property showed the old value? The test led me quickly to spot my error. I was setting the base value, and causing property changed event to get fired, before updating the actual data store. Any code fired by the property changed event that wanted the new value, actually got the old one, since I had not updated the data store yet. Dooh! 

    
 public override double Width
        {
            get
            {
                return this.Model.Width;
            }
            set
            {
                 this.Model.Width = value;     //--setting data store first fixed problem
                base.Width = value;  
                
            }
        }

The PropertyChanged event driven behavior can be tricky to debug since flow of behavior is not immediately evident. This is why testing it even more important, and hopefully the lesson I have learned here is to test first better. As usual I didn’t save time by not testing adequately, I lost time.

Unit Testing Javascript

Recently the project I’ve been working on has been moving more and more towards client side javascript, especially using jQuery. We have been pretty consistent on the server side, especially in our business logic, in creating unit tests. We have over 1,000 unit tests in our business tier leveraging nUnit and Rhino Mocks, that are run every time a check in is done using Cruise Control for continuous integration. Pretty standard stuff for server side logic.

Since we are using more and more javascript why not reap the quality benefits of good unit test coverage here as well?  Considering javascript is non-typed and allows the running of strings as code through the ‘eval’ function it would seem even more important to have good unit test coverage of our javascript.  Up to now we’ve ignored it since it’s been considered UI and not really logic.  With more and more ajax integration this no longer seems like a good practice.

For jQuery driven functionality we have been using the jQuery $.ajax method to call down to asp.net pagemethods located  in web forms we created to support the jQuery functionality.   ASP.net pagemethods are essentially webservice calls located in a webform.  The calls have to be static and must be decorated with the [Webmethod] attribute.   Here is a great blog post going into great detail about exactly how to call an ASP.net pagemethod from jQuery.  We essentially are doing the same thing.  We’ve actually wrapped our $.ajax call so we can centralize error handling and abstract away the ‘.d’ return value you get when the pagemethod does it’s json serialization.

This post is about testing, however, so enough with how we’re using jQuery ajax.   From a testing perspetive what we wanted to be able to do was achieve the same test coverage in our jQuery and javascript as we have on our server side logic.   A little googling and what did I find, but qUnit!  The motif is almost the same as writing tests for nUnit, and when you run your tests qUnit provides default css so test results are shown in a html page in a very similar manner to how the nUnit client shows it’s test results.

The great thing is how easy this is to accomplish.  All you need to do is write tests in a .js file that exercise the code you wish to test using the qUnit syntax.  Then in a html page include jQuery, qUnit, the code you are testing and your test code.  In the html provide the nodes that qUnit will want to write to and, you’re done.   Here’s a very simple html example:

<html xmlns="http://www.w3.org/1999/xhtml" >
   <head>
      <title>QUnit Test Example</title>
        <!-- css from qUnit to make output look good -->
          <link rel="stylesheet" href="http://github.com/jquery/qunit/raw/master/qunit/qunit.css" type="text/css" media="screen">
     <!-- jQuery and qUnit include -->
       <script type="text/javascript" src="/scripts/jquery-1.4.1.js" ></script>
       <script type="text/javascript" src="http://github.com/jquery/qunit/raw/master/qunit/qunit.js"></script>
        <!-- javascript you are testing include -->
       <script type="text/javascript" src="/scripts/ControlScript.js"></script>
        <!-- tests you wrote include -->
       <script type="text/javascript" src="/scripts/ControlScriptTests.js"></script>
   </head>
  <!-- nodes qUnit will write to -->
   <body>
       <h1 id="qunit-header">QUnit Test Suite</h1>
       <h2 id="qunit-banner"></h2>
       <div id="qunit-testrunner-toolbar"></div>
       <h2 id="qunit-userAgent"></h2>
       <ol id="qunit-tests"></ol>
   </body>
   </html>

Very code I’m testing:

[javascript]
function SetupButton(buttonID, txtBoxID, displayText)
{
$("#" + buttonID).click(function() {
$("#" + txtBoxID).attr("value", $("#" + txtBoxID).attr("value") + ‘ ‘ + displayText);

});
}
[/javascript]

And here are the tests I’m running:

[javascript]
test("SetupButtonTest()", function() {

var btn = document.createElement("input");
btn.id = "btn";

btn.type = "button";
document.appendChild(btn);

var txt = document.createElement("input");
txt.id = "txt";
txt.type = "text";
document.appendChild(txt);

SetupButton("btn", "txt", "disp");
$("#btn").click();
equals($("#txt").attr("value"), " disp", "text box has display value: " + $("#txt").attr("value"));

})

test("SetupButtonTest2()", function() {

var btn = document.createElement("input");
btn.id = "btn";

btn.type = "button";
document.appendChild(btn);

var txt = document.createElement("input");
txt.id = "txt";
txt.type = "text";
document.appendChild(txt);

SetupButton("btn", "txt", "disp");
$("#btn").click();
equals($("#txt").attr("value"), "disp", "text box has display value: " + $("#txt").attr("value"));

})
[/javascript]

As you can see qUnit provides a pretty straightforward way to unit test the now more complex javascript we’re writing in our project (the above is just an example, not actual code from our project). The next step is to integrate qUnit into our continuous integration. We would like to have our javascript tests run with every check in, just like our server side tests do. Here is a post on how to do it, it’s seems a little complicated. I will give it a try and put up a post as to the results.

Hopefully we will be able to bring the benefites of good unit testing coverage out from just our server code and now apply it to the more and more complex client side code we’re creating.  After all why would it not be good practice to test code just because it’s javascript?  It seems even more important to test in a language that is non-typed and allows run-time execution of strings as code.

The Rhino Mock Magic Of GetArgumentsForCallsMadeOn

One of the things that occasionally came in handy using Rhino Mocks previous to their AAA linq based syntax was the ability to see if operations on a mock were performed in a particular order. We could very easily set expectations inside and ‘Ordered’ block and if things happened out of order viola! you recieved an exception. Looked like the below:

       [Test]
        public void CompanySaveTest()
        {
            Company comp = new Company();
            comp.Name = "CompanyName";
            comp.Address = "Add1";
            comp.Phone = "222*111*3333";
            comp.User.Name = "Bill";

            int newCompID = 4;
            int newUserID = 2;

            MockRepository repo = new MockRepository();
            IDbManager dbMock = repo.DynamicMock<IDbManager>();

            using (repo.Ordered())
            {
                repo.Expect(dbMock.SaveComany(comp.Name, 0)).Return(newCompID);
                repo.Expect(dbMock.SaveUser(comp.User.Name, newCompID)).Return(newUserID);
                repo.Expect(dbMock.SaveComany(comp.Name, newUserID)).Return(newCompID);

            }
            
            //--Call Method Under Teset
            CompanyManger.SaveNewCompany(comp);

            repo.VerifyAllExpectations();

        }

When we switched to the AAA based syntax there was no way to reproduce the above, at least no obvious way. Luckily we did not require checking order to often, but when we did a co-op on my current project came up with a very effective alternative using the AAA syntax. The method only supports checking the order of operations called against a single mock object, but at least that’s something. Not the full ordered ability of the past, but I’ll take it when it’s handy. At least we can ensure the save calls on the company are in the right order.

The method ‘GetArgumentsForCallsMadeOn’ can be called on a mock after it has been used and it will return a list of object arrays. Each call on the mock will result in a new object[] in the list holding the parameters used in that call. More importantly the object arrays are added as each call on the mock is made, giving us a way to determine if calls were made on this mock in the appropriate order. As simple example looks like the below:

[Test]
        public void CompanySaveTest()
        {
            Company comp = new Company();
            comp.Name = "CompanyName";
            comp.Address = "Add1";
            comp.Phone = "222*111*3333";
            comp.User.Name = "Bill";

            int newCompID = 4;
            int newUserID = 2;

            MockRepository repo = new MockRepository();
            IDbManager dbMock = MockRepository.GenerateMock<IDbManager>();

            dbMock.Expect(db => db.SaveComany(comp.Name)).Repeat.Any.Return(newCompID);
           
            //--Call Method Under Teset
            CompanyManger.SaveNewCompany(comp);

            IList<object[]> args = dbMock.GetArgumentsForCallsMadeOn(db => db.SaveNewComany(Arg<string>.Is.Anything));

            //-- make sure called twice
            Assert.AreEqual(2, args[0].Length);
            
            //--check to make sure called in right order by checking updatingUserIDs of calls
            int updatingUserID = (int) args[0][1];
            Assert.AreEqual(0, updatingUserID);
            Assert.AreEqual(newUserID, updatingUserID);


        }

Now we can check order of calls on the mock object in question. Another nice thing is we can also do checks that were very cumbersume and not very readable in constraints and Arg<> checks in ‘AssertWasCalled’ methods in a much cleaner way.

//--check to make sure called in right order by checking updatingUserIDs of calls
            int updatingUserID = (int) args[0][1];
            Assert.AreEqual(0, updatingUserID);
            Assert.AreEqual(newUserID, updatingUserID);

            Company companySaved = args[0][0] as Company;
            //--check make sure arg is company
            Assert.IsNotNull(companySaved);

            //--now check what ever we like in cleaner way than constraint checking.
            Assert.AreEqual(newUserID, companySaved.LastModifiedUserID);

One thing to remember, however, is that when recording object calls on a mock the references are what it captures. When you do comparisons on reference arguments you are comparing the data as it is on the object at the end of the method. What this means is if you have an object ‘Customer’ and when passed to method ‘UpdateCustomer’ the ‘Name’ property is ‘Larry’ but the property is later changed to ‘Bill’, then the ‘Name’ property will reflect ‘Bill’, it’s state at the end of the method, whenever it is interrogated in an ‘AssertWasCalled’, ‘AssertWasNotCalled’ or ‘GetArgumentsForCallsMadeOn’ regardless of what the property value was when the method was actually called and recorded. This can be a pain when trying to do asserts, but such is life. In these cases you have to do the argument check on an expect previous to the mock being used.

Handling Dependent Expected Results

Recently the question came up as to how to handle creating expected results for a unit test when those results rely on a call to an outside helper function. As an example, in our current project we have a “Name” class that has methods for creating a string that is formattted to be first name then last name and another function to create a string that is last name comma first name. The name class looks a little bit like the below example:

public class Name
{
    public string FirstName
    { get; set; }

    public string LastName
    { get; set; }

    public string GetFirstNameLastName()
    {
        return this.FirstName + " " + this.LastName;
    }

    public string GetLastNameFirstName()
    {
        return this.LastName + ", " + this.FirstName;
    }
   
}

The question that arose was what to do in tests where some expected result had been manipulated by a helper method, such as one of the name formatting methods in our “Name” class. For instance, let say we had a report class that created one row per customer wtih some information about that customer. The first field of the report is supposed to be the customers name formatted as last name comma first name. In the code we’re using the the ‘ GetLastNameFirstName()’ method of the name object to get the string the report class is printing. Let’s say the report has a ‘ReportDataSource’ that takes a Customer object that has ‘Name’ property called customer name and sets a string ‘Name’ as such: (Below is not real just for example sake)

public class ReportDataSource
{
    public string Name;

    public void FillItem(Customer customer)
    {
        this.Name = customer.CustomerName.GetLastNameFirstName();

     }
}

Let’s say we have a unit test for this that looks like the below, the gist of the question is what should we set as the ‘excpectedName’? (Below test would be overkill itself in reality, again just for exlanatory purposes)

 [Test]
public void GetCustomerName()
{
    //--Arrange

    string expectedName = "";

    Customer cust= new Customer();
    cust.CustomerName.FirstName = "first";
    cust.CustomerName.LastName = "Last";
    
    
    ReportDataSource reportData = new ReportDataSource();

    //--Act
    reportData.FillItem(cust);

    //--Assert
    Assert.AreEqual(expectedName, reportData.Name);
}

We came up with three possiblities, we could hardcode the value so we’d have a line that looked like the below:

string expectedName = "Last, First";

Hard coding seemed fine and makes the test very explicit. The worry for some was what happened if we changed the behavior of the ‘GetLastNameFirstName()’ method? Then we would have to go manually change all the places where we’d hard coded what we expected it to do.

I agreed this was a concern, but my thinking was from a testing perspective we weren’t concerned with how the method did it’s work, we wanted to see that exactly that hard coded string was returned in our test given the input we’d provided. Someone pointed out that this wasn’t necessarily the case, we did not really want to test for our hard coded string since we wanted to rely on the Name class, and we did want any changes there to not break out test. The entire reason for centralizing name formatting was so changes in name formatting would only have to be made in one place. I had to agree.

The next thought if we wanted to make sure the Name object was involved was to mock the Name object.  This sounded like a good idea, we want to rely on the Name object and wanted our test not to break if the Name object changes it’s behavior.  However, as I thought about this it started to seem like overkill. To easily mock the Name object we’d have to extract an interface and go through the extra effort of creating and programming a mock in testing to isolate the behavior of a method that just turns around a name?

I could see this being necessary if the method did something that wasn’t repeatable.  Lets say in our method we were creating a GUID, well we’d have no idea what each new GUID would be, we’d have to mock the call to create our GUID if we wanted to test any output that contained the GUID.  Every call to the “GetLastNameFirstName()’ method will produce the exact same output given the same input.   Which lead me to the solution I liked best.

Given that the ‘GetLastNameFirstName()’ method will produce the expected result we want, and if it’s behavior changes we want to expect the new behavior, why not use the method itself to create our expected result?  Something like this:

[Test]
        public void GetCustomerName()
        {
            //--Arrange

           
            Customer cust= new Customer();
            cust.CustomerName.FirstName = "first";
            cust.CustomerName.LastName = "Last";
            
            //-- use the dependent method to create the test data since we don't want
            //   to test the dependent method just want to make sure we're always consistend with it
            string expectedName = cust.CustomerName.GetLastNameFirstName();
            
            ReportDataSource reportData = new ReportDataSource();

            //--Act
            reportData.FillItem(cust);

            //--Assert
            Assert.AreEqual(expectedName, reportData.Name);
        }

Some still preferred the idea of mocking, but this worked best for me. If the method is deterministic and doesn’t rely on anything outside the immediate application domain, why not let the method act as it’s own mock? This allowed us to not be dependent on the behavior of the methods in the Name class as any changes cause changes in our expected results. We also can avoid the extra effort for mocking. I like it!

Unit Testing LINQ To LLBL

In many of the projects I’ve been working on we use an ORM tool called LLBL Gen Pro.  This tool provides a LINQ implementation that allows us to to select objects from our data source using LINQ query syntax.  An interesting obstacle we encountered was how to unit test code that used LINQ queries passed to LLBL.

For unit testing we did not want to actually hit our database, we wanted to isolate the code under test and ensure that it did what we intended.  Our first thought was to mock the IQueryable interface.  However, in the context of a LINQ query this didn’t seem feasible.   When mocking an object usually we provide a  mock implementation as a stand in and have it provide return values when needed and otherwise track the the object being’s mock usage.  It wasn’t immediately obvious how we would program a mocked IQueryable interface or what calls would be made against it during a particular LINQ query.

Instead of providing a mocked IQueryable interface we realized we could simply create an “in memory” test database of sorts for our tests.  Generic lists provide an ‘AsQueryable’ method that return their contents as an IQueryable.  In order to make our select logic testable we have our methods take the IQueryable to select against as a parameter.  When running for real the IQueryable parameter passed to the method is the data object that really hits the database, when under test  a generic list is passed in.  A very simplified example method might look like the below:

public List<SchoolEntity> GetList(SchoolFilter filter, IQueryable<SchoolEntity> schoolQ)
        {

            var result = from school in schoolQ
                         where school.Name == filter.Name
                                 && school.Colors == filter.Colors
                         select school;

            return result.ToList();

        }

In order to test we can create a list to pass in to our method:

[Test]
 public void TestSchoolColorFilter()
 {
 //--Arrange
 SchoolFilter filter = new SchoolFilter();
 filter.Colors = "Blue";

 List<SchoolEntity> schools = new List<SchoolEntity>();

 SchoolEntity school1 = new SchoolEntity();
 school1.Colors = "Blue";

 schools.Add(school1);

 SchoolEntity school2 = new SchoolEntity();
 school2.Colors = "Purple";

 //--Act
 List<SchoolEntity> retVal = GetList(filter, schools.AsQueryable());

 //--Assert
 Assert.AreEqual(1, retVal.Count());

 }

When actually running the method is called after a reference to an IQueryable object from the database is created and passed in like the below:

public List<SchoolEntity> GetList(SchoolFilter filter)
 {
         using (DataAdapter data = new DataAdapter())
         {
            LinqMetaData meta = new LinqMetaData(data);
            return this.GetList(filter, meta.School);

         }

 }

This allows us to take advantage of LLBL’s LINQ to LLBL functionality but still create unit tests that don’t have to cross the boundary to the database in order to run. So far it’s helped us to keep our code less coupled and more cohesive. The next hurde, and another post, is how we handle unit testing when LLBL specific LINQ extension methods are involved, aka Prefetch Paths!