3

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.

Community
  • 1
  • 1
Yakitawa
  • 169
  • 1
  • 8

2 Answers2

4

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).

Evren Kuzucuoglu
  • 3,781
  • 28
  • 51
  • Thanks for the answer! I will not use partial classes... However! I found an example on the wiki side, https://en.wikipedia.org/wiki/Separation_of_concerns, that expresses SoC as partial classes. Dijkstra describes SoC as a way of helping the programmer to seperate concerns and not necessarily helping the program to seperate concerns. Wouldn't it still be sensible to use partial classes and still have a "good" SoC in my case? I see that partial classes are well suited for auto-generated code, but should this exclude it of being good for splitting UIMaps? – Yakitawa Aug 14 '15 at 09:20
  • I'd argue SoC is rendered more useful in C# today by the fact that the language enforces scoping strictly (as opposed to Powershell or Javascript for instance), by modern development techniques where we avoid global state (by using injection and avoiding static objects), and by the fact that the tools we use are presenting our code in higher level than was common in the past (think VS Intelisense or ReSharper, for those tools partials are meaningless). – Evren Kuzucuoglu Aug 14 '15 at 14:50
1

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.

AdrianHHH
  • 13,492
  • 16
  • 50
  • 87
  • Thank you very much for your answer! I am very aware of the advantages of splitting the UIMap, but I would like to postulate, that the advantages are still met using partial UIMap classes... Of course, your 5th point(Memory and CPU usage) would be a problem using partial UIMap classes, but I have not found any evidence on this either - My best guess is, that Visual Studios compiler magic would be smart enough to not instantiate the fields and methods of a class which are not used during a test method. After all, the UIMap is disposed between each testmethod. Do you think this is plausible? – Yakitawa Aug 14 '15 at 09:03
  • @Yakitawa How would you split the UI Map into many files each starting `partial class UIMap {` without losing all of the power of the UI Map editor? – AdrianHHH Aug 14 '15 at 11:27