WPF automation – projects structure

Last Updated on by

Post summary: How to structure projects in the course of WPF automation.

References

This post is part of Automation of WPF applications with Telerik Testing Framework and TestStack White series. Sample application can be found in GitHub SampleApp repository.

Overview

For better maintainability and good design automation testing is separated in two projects. One is the so called framework project. It has knowledge about third used party frameworks (Telerik Testing Framework, TestStack White, Selenium, Watij, etc.). It operates on elements via those third party frameworks. Framework exposes actions that are building blocks of the tests. The other project are the tests. It doesn’t know anything about used automation frameworks. It uses methods exposed by internal framework and builds the tests with them. The idea is that one team/person with development knowledge can be responsible for the internal framework, others can be responsible for writing well designed tests using the internal framework only. Another benefit from two projects is ability to completely change internal framework project without affecting test logic at all. Here is the structure of my sample projects:

Projects structure

Projects structure

SampleApp – This is the application under test. Generally it is not in the test project, you receive it from developers or from nightly build or from some other place. For the purpose of this demo I’ve created very basic application that uploads and image and shows it inside. There is attached image (HappyFace.jpg) that is used in the tests.

SampleApp.Tests – Here is the most important artefact – the tests, the purpose of all this fuss. In the demo this is made as UnitTest with MS Unit Testing Framework. You can use what ever run strategy you like – another unit testing framework (xUnit, nUnit, etc.) or you can build you own tests runner. I have build my own tests running because by definition unit tests should be independent from each other thus MS Unit Testing Framework runs them in random order. It might be possible to manage order, but this will require managing of some sort of external files. It gives too much overhead to me.

SampleApp.Tests.Framework – This is where the interesting part is. Here are the elements – main application form (WPF), message boxes shown on success or error (WinForms) and open file dialogue (WinForms). MainWindow is manipulated with Telerik Testing Framework, other two are manipulated with White. App.cs is a holder which represent application itself and elements are access through it. BaseTest holds and instance of App. It is extended by UnitTests and App and its elements are accessible.

Next post is WPF automation – locating and structure of WPF elements in code.

If you find this post useful, please share it to reach more people. Sharing is caring!
Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone