In my last post I had a look at Microsoft’s new Integration Testing platform for web applications, the Lightweight Test Automation Framework. I’ve had some feedback from one of the developers for the framework and I’ve decided to take a look at how we can address some of the issues I raised, rather than just moan about them.
Firstly, they have started calling the project LTAF so I will be doing the same.
In this post I will try and solve one of my main concerns with the framework – no automated build support. While support for integrating with a build process is in the pipeline, I’m going write a quick implementation that can be used until then. This was done using the June update of LTAF.
Writing a Test Runner
Automating the Request
LTAF contains support for selecting and running tests through parameters passed in the url. The default mechanism for selecting tests is to mark them with a certain tag (in code) and then specifying that tag in the url. We can also specify that the tests must be run automatically and the results must be logged. In this case we want to run all the tests, so the url will look something like this:
If you open this url in your browser all tests will be executed and the results will be written to a file called TestLog.txt in the same directory as the test page (by default this is in the \Test folder).
Let’s write some code
I implemented the runner as a console application. I am also passing 2 parameters via the command-line: the url of the website and the directory where the website resides.
The console application parses the arguments, starts the request and writes the results to the console window.
Nothing to it. For the tests to run you first need to host your website, either through the ASP .Net Development Server or through IIS. By default Visual Studio will host your website using the Development Server.
When the run is completed I write the output to the console window and look for any failed tests. Setting the exit code should indicate a failure – for most Continuous Integration solutions this should cause the build to fail.
Unfortunately the results from the log file aren’t very informative – I would prefer to see the time each test took to run as well as the stack trace from any failed tests.