Sunday, April 27, 2008

Unit-testing private methods

Suppose you have a class that has some private methods and you want to make sure these methods function correctly, so you want to write unit-tests for them. The problem is that you can't call these methods, because they are private.

The class we want to test:

public class ClassWithPrivateMethods
{
     public int Add(int firstNumber, int secondNumber)
     {
         return firstNumber + secondNumber;
     }

     private int Substract(int initialNumber, int numberToSubstract)
     {
         return initialNumber - numberToSubstract;
     }
}

Testing the "Add" function is simple. It's public, so we can just call it from a unit test:

[TestMethod]
public void TestAddition()
{
     ClassWithPrivateMethods classToTest = new ClassWithPrivateMethods();
     int result = classToTest.Add(5, 5);
     Assert.AreEqual(10, result);
}

Testing the "Substract" function is a problem. You can't call the method from the unit-test. One way around this is creating a new class, specific for the unit-test, that inherits from the class you want to test and use the "new" keyword to make the function available as a public function. The problem with this approach is that the method can't be private. It has to be protected at the minimum:

public class ClassWithPrivateMethods
{
    public int Add(int firstNumber, int secondNumber)
    {
        return firstNumber + secondNumber;
    }

    protected int Substract(int initialNumber, int numberToSubstract)
    {
        return initialNumber - numberToSubstract;
    }
}

Which means you'll have a test class like this:

private class ClassWithPrivateMethods_TestWrapper : ClassWithPrivateMethods
{
    public new int Substract(int initialNumber, int numberToSubstract)
    {
        return base.Substract(initialNumber, numberToSubstract);
    }
}

And a unit-test like this:

[TestMethod]
public void TestSubstractionInt()
{
    ClassWithPrivateMethods_TestWrapper classToTest = new ClassWithPrivateMethods_TestWrapper();
    int result = classToTest.Substract(10, 5);
    Assert.AreEqual(5, result);
}

I've done this before and it works well. But this way you still can't have private functions.
Enter reflection.
With reflection you can do anything you want to the class. Even invoke private methods! So we'll change the helper class into this:

private class ClassWithPrivateMethods_TestWrapper : ClassWithPrivateMethods
{
    public int Substract(int initialNumber, int numberToSubstract)
    {
       Type t = typeof(ClassWithPrivateMethods);
       return (int)t.InvokeMember("Substract", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.InvokeMethod,
       null, this, new object[] { initialNumber, numberToSubstract });
    }
}

Ofcourse you don't really need the wrapper class, you could just as easy put these two lines of reflection stuff inside the unit-test if you wanted. But if you do use the wrapper class, you can just instantiate it and call the "Substract" method for your unit-testing purposes, just like the unit-test above.
This also works for methods that have been overloaded for multiple data types. Suppose we have the following class we want to test:

public class ClassWithPrivateMethods
{
    public int Add(int firstNumber, int secondNumber)
    {
        return firstNumber + secondNumber;
    }

    private int Substract(int initialNumber, int numberToSubstract)
    {
         return initialNumber - numberToSubstract;
    }

    private float Substract(float initialNumber, float numberToSubstract)
    {
        return initialNumber - numberToSubstract;
    }
}

Our wrapper class would look like this:

private class ClassWithPrivateMethods_TestWrapper : ClassWithPrivateMethods
{
    public int Substract(int initialNumber, int numberToSubstract)
    {
        Type t = typeof(ClassWithPrivateMethods);
        return (int)t.InvokeMember("Substract", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.InvokeMethod,
        null, this, new object[] { initialNumber, numberToSubstract });
    }

    public float Substract(float initialNumber, float numberToSubstract)
    {
        Type t = typeof(ClassWithPrivateMethods);
        return (float)t.InvokeMember("Substract", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.InvokeMethod,
        null, this, new object[] { initialNumber, numberToSubstract });
    }
}

And you can unit-test like this:

[TestMethod]
public void TestAddition()
{
    ClassWithPrivateMethods classToTest = new ClassWithPrivateMethods();
    int result = classToTest.Add(5, 5);
    Assert.AreEqual(10, result);
}

[TestMethod]
public void TestSubstractionInt()
{
    ClassWithPrivateMethods_TestWrapper classToTest = new ClassWithPrivateMethods_TestWrapper();
    int result = classToTest.Substract(10, 5);
    Assert.AreEqual(5, result);
}

[TestMethod]
public void TestSubstractionFloat()
{
    ClassWithPrivateMethods_TestWrapper classToTest = new ClassWithPrivateMethods_TestWrapper();
    float result = classToTest.Substract(10.0f, 2.5f);
    Assert.AreEqual(7.5f, result);
}

Wednesday, April 23, 2008

The blame game, or: It works on our end.

The system I'm working on is in the end-to-end testing phase. It's being tested for the past 2 weeks or so and today the testers ran into an issue where request that they sent from the first system  timed-out. Their view on the issue: It's our problem.

So we did some problem analyses. We checked some log files, but we never even saw a request coming into the webserver. Then I sent the same request they we're trying to do and it got accepted, it got processed and they even got the callback to notify that the request had been completed. So we established that our system worked. Even the engineer from that other system agreed to that.

So the engineer went to check on stuff. And at the end of the day I got an e-mail that basically stated:
"We checked everything. The request is correct and we have the correct URL configured. So the only conclusion in that is must be a problem in [the system I work on]. And we'd like them to solve the problem ASAP."

This reminded me on a joke I read in David Platts excellent Why Software Sucks...and What You Can Do About It.  It's a joke about Microsoft in  a chapter about Microsoft. The short version is something like this:

A Microsoft engineer goes into the army and needs to shoot at the shooting range, but he misses every time. The drill-sergeant  gives the Microsoft engineer craps and tells him to do better. At which point the engineer holds his finger in front of the nozzle of the gun and shoots his finger off. Then he points the bloody stump towards the target and says: "Well, it comes out here alright, so the problem must be on their side".

This is exactly what I thought about when I read that e-mail and it's this kind of shortsightedness  that really pissed me off. A good engineer, in my opinion, always assumes the problem is in his code. Only after very careful examination and testing should you state it's probably a problem on the other side. And even then the engineer should fully cooperate in finding out the problem. After all, it's not like we're competitors. We're all building parts for the same product and work in the same company on the same goals.
With this kind of thinking we'll never deliver a good system.

Tuesday, April 15, 2008

LINQ means working fast

Now granted, I have not yet done a really big project with LINQ and I have really limited experience with LINQ so far, but let's not kill the hype here, okay? :-)

At my office we have almost finished our part in a whole connected chain of systems to provision products that my company offers to its end-users. The system we build is an abstraction on top of the technical provisioning systems and through our system they are integrated for use by the commercial systems at the top of the chain. In the beginning of last week they told me that one of the big commercial system would need more time to get done. "More time" in this case meant around a month. Knowing how good estimates by programmers are, I'm positive it will be more then a month, but I digress. Even with that delay, they still want to start the pilot project and start using parts of the provisioning chain. So they asked me to build a kind off web-front-end to our system. So that they could start handling orders manually at the very least. And while the big commercial system was delayed for (at least) a month. They asked me to do it in 2 or 3 days. And because they were desperate they told me to build it no matter what. The front-end would contain next to no logic and would only need to communicate with out system, which I know very well, so I decided to build it with some new technology I was itching to try out, so I chose to build it with ASP.NET MVC and LINQ.

I had played with ASP.NET MVC before, but they updated the preview bits and I found some welcome changes. Aside from spending some extra time in getting the URLs to look nice it wasn't really that challenging. No, the fun part was in using LINQ.

In my team we have defined a set of "best practices" or some development "rules" and one of the rules is that we always use Stored Procedures (sprocs). So when I write a Data Access Layer (DAL) for any program I always create a data-model (the database tables), then I create sprocs for all the things I need to do to the data that will be stored in the database (reads, inserts, updates, etc) and then I will write some C# code to access these sprocs and to create C# objects out of the returned data (and of course code to be able to input data to the sprocs). This time I chose to go with LINQ and I've never written my DAL in such a short time. Even if I still had to find out some basic things on how to use LINQ.

I think that I wrote my DAL with LINQ in less then 20% of the time it would have taken me if I had to use our 'conventional' way. It's so simple. Now, be aware that I did not do any complicated stuff here. Just you basic selects, inserts and left outer joins. Nothing more. But I think that's exactly where the strength of LINQ lies. All the simple stuff is trivial to do in LINQ, but takes more effort to do as sprocs and SqlDataReaders. Why waste your valuable development time on that?

I encourage every developer out there to try LINQ. Give it a good whirl and don't judge the LINQ book by its cover. Yes, it generates dynamic SQL, but I've some tests (some very unscientific tests) and found that LINQ is faster then using SqlDataReader with sprocs on simple queries. I just took a large table (500,000+ items) with some 12 columns and made an sproc and a LINQ query (that resulted in the exact same SQL as the sproc) and did some loop testing. When doing the same query as fast as possible in a loop, LINQ will be faster then the SqlDataReader/sproc method until around 300 queries. After that LINQ seems to be getting slower. Personally I think this has to do with the fact that for the sproc SQL Server only needs to see a single word (the name of the sproc) to recognize what you want and re-use it's caching, whereas with the LINQ query it will need to compare the whole query to notice it already exists in the cache. And maybe network traffic also plays a role. Network traffic is less with an sproc. So with these test results in mind, sprocs would only be faster if you have a really high-traffic site (but even then you should measure before you start to optimise). And if you want to be Agile. You'll release early and often. So you can start cramming out features while using LINQ for your DAL so you won't waste precious time on sprocs and such, and then replace the LINQ DAL with an sproc DAL when you start to notice the performance hit. Or you combine them, which is also entirely possible.

Sunday, April 6, 2008

About being a good programmer

I consider myself to be a good programmer. I am my own worst critic, I always question methods and don't use methods "just because I did last time". I always assess if they are appropriate for the new challenge.
I also try to keep up with new technologies and trends in development and although I can be a bit too enthusiastic about certain things, I never really use new technology just because it's new.

At the office my team is currently at the end of a very big (for us) project. As always, the time was short and the deadline was set in stone, but no one really knew exactly what we had to build. So me and 6 colleagues started working on the project. It was jump-started by a Software Architect, who created the very basic architecture and then I took over.
The system is basically a routing and handling system for product provisioning and we envisioned a program where we would just write a plug-in for a specific product to handle the product specific tasks. That way we can easily extend the system for new products.
In the initial planning we had the system to handle 4 products, of course this soon turned into 5 products and then 6 products. So me and two other colleagues set off, each assigned his own product(s), to build the plug-ins.
One of the colleagues copied the basic architecture of his plug-ins from my plug-ins, but the other colleague took a whole different route.

After initial programming was done and we were in the test phase, we finally had time for code reviews. So as I was reviewing the code of the colleague who took a very different route then I did, I found it hard to determine what he was doing. I didn't get it and his solution seemed overly complex to me. Then he explained his architecture....

I was shocked. His architecture was much better then mine. I was so set in the mind-set of my architecture that I failed to see the beauty of his decisions. I was shocked and ashamed. Ashamed because I thought my design was better then his before he explained it to me.

This reiterated a very important lesson to me. I am not perfect, I won't always do the best thing. I might not even be close from time to time.
One of the things I consider add to me being a good programmer, is that I will admit if I am wrong and that I will accept a better solution, even if my solution was the inferior one. I'm not too proud to admit I am not perfect, but somehow, this time, it kind of sneaked up on me.

The lesson I take away from this? Don't judge too soon and don't think you've got the best solution. There will always be a better solution.