Coded UI testing: What is the reasoning behind creating multiple individual UIMap classes instead of just multiple partial UIMap classes?

Question

I am working on a project which includes a "semi-big" application GUI. There are about 4-5 individual(complex) pages I want to perform Coded UI Tests on, and I have gotten the impression that creating multiple UIMaps is the way to go! Sources: UIMap container, Using multiple UIMaps, More source and the list could go on...

My problem/thought: Using multiple UIMaps is "nice" because it:

1. allows a more categorized structure of the code
2. allows easier cooperation between developers
3. makes the code less daunting to maintain.

But why is no one merely chopping the UIMap up in multiple partial classes? Wouldn't it still have the same advantages? Even further: Having the UIMap in partial classes will prevent the developer(me) from adding complexity to the code like UIMap container.

Answer 1

This question is not really specific to CodedUI. Using partial classes to simulate separation of concern is not the correct way to go.

They might make writing a class easier, but they do not create proper separation of concern (which is the underlying reason behind the existence of classes) and thus do not make using the class easier, since from an external point of view there is no difference at all between a class with code written in one or several files.

To give a simple example, you will have auto-completion return a flat list of all the members of your class accross all partial files without distinction.

Partials are used when a class is part generated code part non-generated code, or written in different languages (xaml and C# for SL/WPF for instance). The different bits might cover parts of the same behaviour, hence it makes sense (from an SoC point of view) to group them under the same class, but from a code management perspective, the two parts need to be separated. This is why CodedUI uses partials (*.Designer.cs files are generated, while *.cs files are not).

If you feel the need to create partials to have separation of concern, then you should probably take a step back and use proper SoC (i.e. create different classes).

In the specific case you are exposing, I would consider creating UIMaps for different sections of your application UI (whether your are separating the behaviour of your UI into different windows, or sections of windows, etc - depending of the complexity of it).

Answer 2

There are several reasons for using multiple UI Maps rather than one big map. Some of them are:

• UI Maps are hard to clean up. As the test suite evolves the UI Map get more and more old and unused items. There is virtually no support for safely removing unwanted pieces.

• Having many UI Maps means that different test developers can be productive at the same time without generating clashing items in the main UI Map. Whilst a ".uimap" file is a simple text file it contains XML. Successfully merging these files in the manner common with configuration management systems would be somewhere between very difficult and impossible.

• Having many UI Maps with one per test, means that when a test is no longer needed its UI Map can be thrown away. All of the support for that test specific is cleanly discarded.

• Having many UI Maps with one per page of an application means throwing a UI Map away and creating a new one for page is relatively cheap.

• Big UI Maps consume lots of memory and CPU time. Anecdotally using a big UI Map can make the test suite very slow (I do not have real evidence of this). A big UI Map has large numbers of members and nested classes. It is easy to imagine that the run time data needed to manage such a class is large and consumes lots of memory and CPU cycles.

• Having many UI Maps rather than one big one means that experimenting can be done without adding lots of unnecessary items to the main project map.