Posts Tagged ‘Testing’

Web Integration Tests – with or without the browser

November 24, 2008

In this post, I would like to go in the topic of web tests – automatically verifying the functionality of a full deployed web site.
Automating the browser has been a popular approach, which gives the benefit of testing the site, as the user sees it, including images, css files and secondary functionality implemented with javascript as Ajax.
Internet Explorer can be automated through its COM API – this is a popular approach that is being used by several open source and commercial libiraries like watin and watir.
Other innovative way is taken from the selenium framework, which uses javascript to simulate user actions, which makes it portable across browsers and operating systems.

Automating the browser there is one big problem though – the tremendous amount of web requests issued for loading the complete page, including all images, css files, ad banners and so on, which can be a big performance hit if you have a lot of tests. While it is important to verify, that everything is properly deployed, all images are found and so on, the loading of all this secondary clutter does not provide any benefit for the functional tests and just slows the execution time.
When the tests run for several hours it is very difficult to use them as a feedback mechanism about the project status. Slow tests aren’t used by the developers and at the end, aren’t used at all and provide little or no value the project.

Confronted with this problem the test engineering team at AutoScout took another approach – testing without the browser, using direct http requests. This technique appears a little more challenging to use, but cuts the tests execution time by orders of magnitude. Our http tests run for a minute and half and provide very fast and reliable feedback, which makes them very useful.

If you want to use direct http tests there are several ways to write them – for .NET you can use the MS Test library that ships with Microsoft Visual Studio Testing Edition, or the HttpWebRequest/HttpWebResponse classes in the System.Net namespace. For MS Test library you have to install Visual Studio Tester Edition on your build servers.
For java there is the HttpClient package from apache. We ended up using our own small http implementation, optimized for testing purposes.
If there is interest about it, I would gladly go into more detail about it.

I would like to point out, that using direct http test requests does not replace browser tests when comes to testing ajax functionality and deployment issues of the secondary files. Our advice would be to use direct http tests when you can and browser tests when you have to. Combining the best of both worlds has given us satisfying test coverage and feedback speed.

Happy testing!

Unit Tests 101 – how to write testable code

November 22, 2008

Reposting this entry I wrote for my company’s blog

Hi, I am Test Engineer at AutoScout24 in Munich and will be writing about Unit Tests, testability, Acceptance Tests and developing high quality software. In this post I want to go in go into the testability topic – what makes code testable and what not. It may seem obvious how to do it for the people, that are going the TDD way, but sometimes it is hard for new developers to adopt the art of writing Unit Tests.
Writing Unit Tests is all about being able to use the classes you develop in isolation, without having to instantiate their external dependencies, or a database, filesystem, webserver or something else running.
So it all boils down to the question – how to make the class dependencies exchangeable. Let’s assume we have the following code:

Code:

public class ClassInTest {
 public bool DoStuff() {
   IExternalDependency dependency = new ExternalDependency(...);
   return dependency.Something();
 }
}

Unit Test:
impossible to write

For this example we have pretty simple code to test and just want to concentrate in making it testable.
The main issue with this code is that, the class instantiates the ExternalDependency by itself. Considering that when writing an Unit Test we are interested in the functionality of ClassInTest only, we would like to ignore the ExternalDependency and replace it with some kind of fake implementation

The first approach would be to encapsulate the object instantiation with a static method within the class.

Code:

public class ClassInTest {

  static IExternalDependency dependency;

  public static IExternalDependency CreateExternalDependency(...) {
    if(dependency == null) {
      dependency = new ExternalDependency(...);
    }
    return dependency;
  }

   public static void SetExternalDependency(IExternalDependency aDependency) {
     dependency  = aDependency;
   }

   public bool DoStuff() {
     IExternalDependency dependency = CreateExternalDependency(...);
     return     dependency.Something();
   }
}

Unit Test:
public class ClassInTestTest {
  public void DoStuffTest() {
    IExternalDependency mock = new Mock<IExternalDependency>();
    mock.Expect(x => x.Something()).Returns(true);
    ClassInTest.SetExternalDependency(mock.Object);

    ClassInTest classInTest = new ClassInTest();
    Assert.IsTrue(classInTest.DoStuff());
  }
}

To go one step further we could write a class responsible only for object creation – a factory.

Code:

public class ClassInTest {

  public bool DoStuff() {
    IExternalDependency dependency = CreateExternalDependency(...);
    return     dependency.Something();
  }
}

public class ClassInTestFactory {
  static IExternalDependency dependency;

  public static IExternalDependency CreateExternalDependency(...) {
    if(dependency == null) {
      dependency = new ExternalDependency(...);
    }
    return dependency;
  }
}

  public static void SetExternalDependency(IExternalDependency aDependency) {
    dependency  = aDependency;
  }
}

Unit Test:
public class ClassInTestTest {
  public void DoStuffTest() {
    IExternalDependency mock = new Mock<IExternalDependency>();
    mock.Expect(x => x.Something()).Returns(true);
    ClassInTestFactory.SetExternalDependency(mock.Object);

    ClassInTest classInTest = new ClassInTest();
    Assert.IsTrue(classInTest.DoStuff());
   }
}

This way we have clean separation between classes, that know how to create objects and classes who do the actual work. As a side effect we have to write a factory class for every second class in the application.

The last and clearly the best approach we are going to examine is the dependeny injection path – let all the wiring work to an external container, which knows how to create all registered classes and do not bother writing code for this yourself, be it a static method within the class or factory. The point is to have each class to declare its dependencies in the constructor or as properties

Code:

public class ClassInTest {
  public ClassInTest(IExternalDependency dependency) {
    this.dependency = dependency;
  }

  public bool DoStuff() {
    return     dependency.Something();
  }
}

Unit Test:
public class ClassInTestTest {
  public void DoStuffTest() {
    IExternalDependency mock = new Mock<IExternalDependency>();
    mock.Expect(x => x.Something()).Returns(true);

    ClassInTest classInTest = new ClassInTest(mock.Object);
    Assert.IsTrue(classInTest.DoStuff());
  }
}

This is clearly less code and makes it easier to test, the important thing is to examine the client code – how is ClassInTest used in production, without the container:

Client Code without usage of dependency injection container:

ClassInTest classInTest = new ClassInTest(new ExternalDependency());

In real life when you have a lot of dependencies, each of them having a lot of other dependencies it is very hard burden to pass all the arguments by yourself. Let the container do it for you.

Client with dependancy injection:

ClassInTest classInTest = container.Resolve<ClassInTest>();

Notice that you don’t have to bother what does the ClassInTest need to be instantiated. The “magic” is that IExternalDependency is registered within the container, so we just request some object and let the container do the heavy lifting – examining what constructors it has and resolving the needed arguments.

If are you looking for dependency injection container you can try AutoFac, Castle Windsor, StructureMap or Microsoft Unity, just to name a few.

It is not always possible to switch to dependency injection in a large project – then factories are you best choice. But keep in mind, that dependency injection is the way to go and do your best to prepare your project for it.

Happy programming!