Jake Ginnivan's blog

TeamCity UI Test Agent

Setting up a UI Test build agent

Many UI automation frameworks automate not only using automation patterns, but also automate your mouse and keyboard. This means that you need a fully unlocked desktop for things to work correctly. This blog post will show you how to setup a UI Test agent on Azure VM’s, but you can use your own vm infrastructure.

I recommend using a VM, because otherwise you are leaving a desktop unlocked where anyone can come and use it. At least VM’s run on a locked desktop, or on the cloud and you need to remote in.

Setting Up Git

I have setup git many times for myself, and also team members. I thought I would just share the way I install and setup my Git environment on Windows.

I use Git Extensions as my Gui when I am not using the Command Line (which is my preference). It also is bundled with KDiff3 and MsysGit which means you only have to download one things.

TeamCity Build Results in TFS

Why?

Recently I have been working with testers on our team, and trying to bring testing closer to our sprints. We use Microsoft Test Manager for our test tool, TFS for work items, GitHub for source control and TeamCity for our build server.

All our tests are written using xUnit.net. When you start working with testers it becomes important to surface your automated and manual testing together, so testers can work more efficiently and have more confidence in the software the team is producing.

Enter TFS. TFS is a great product that starts really value adding when you use different components together, the testing tools is an example of this. When you use Team Build with the testing tools, a heap of features and workflows start working way better!

What?

My goal is to have my automated regression tests (both UI and Integration tests) which are written in xUnit to report their results back into TFS (Builds) and Test Manager (Test Runs).

This allows the Testers to use the planned automation features in TFS to mark certain Test Cases as ‘Planned’ for automation, it also lights up a whole lot of reporting around test case readiness and other things.

Awaitable DelegateCommand

Most of you would be aware of DelegateCommand, it allows you to turn a lambda (or two if you want to specify canexecute) into a WPF ICommand.

This is pretty easy to unit test as well, you can simply go viewModel.MyCommand.Execute(null)

But this falls down when you start using async, because the lambda will end up being an async void method. This means your test can no longer observe what happens in that command. If the implementation throws, your unit test will not know about it and then your test process will crash (if using .net 4.0).

Read Lucians blog post for more information about why async void is bad.

So we introduced a new interface, called IAsyncCommand and it looks like this

Announcing TestStack.White

Project White

For those that don’t know, project white has been around for ages. It has gone from Google Code (https://code.google.com/p/white-project/) to Codeplex (http://white.codeplex.com/) then GitHub (https://github.com/petmongrels/white).

The goal of White was to create a nice abstraction over Microsoft’s UI Automation framework in a consistent and object orientated way.

White reached a nice maturity level and active development stopped about 2 years ago, since then things have moved on.

Vivek Singh has given me permission to take this project over and try and increase the activity on this project again.

Why I’m taking on White

Personally, I have been on a rather large WPF project on and off for the past 2.5 years and rely on UI Automation very heavily. When we started the project, White was the most mature UI Automation framework.

This is a snapshot of some of our builds, every CI build that succeeds with kick-off many UI automation test runs for different configurations.
TeamCity

Over the last few years, we have wrapped White and have been running a custom builds and have learnt a lot about UI automation.

I would like to put some of the learnings and improvements back into White to make it easier for everyone to use UI automation without paying for one of the commercial offerings.

One of my colleagues at Readify, Mehdi Khalili did a presentation at Perth .NET usergroup on UI Automation, he was suggesting many things that we were already doing on this project except he was focusing on Web Automation. Mehdi created BBDify a while ago, which got renamed to BDDfy when Mehdi, Michael Whelan and Krzysztof Ko┼║mic formed TestStack.

After talking with Mehdi in the pub, he convinced me that I should restart White, and also join TestStack so we can keep some great testing related projects together!

TestStack.White

I have been doing some updates and cleanups on White over the past month or two in a private repo, but I have now opened it up at https://github.com/TestStack/White.

I am looking forward to working on White some more, and I welcome pull requests :P

Async Warning With nSubstitute

I got sick of a heap of warnings in VS which look like this:

Warning 1   Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the 'await' operator to the result of the call.

The code which was causing this error was a received call: _service.Received().CancelAsync()

My solution to the problem is creating a simple extension

public static class NSubstituteHelper
{
    public static void IgnoreAwaitForNSubstituteAssertion(this Task task)
    {

    }
}

Then my code turns into _service.Received().CancelAsync().IgnoreAwaitForNSubstituteAssertion() and my issue goes away