Coded UI: Data Driven testing

In this one, I’m adapting the existing HTML test to allow tests to be driven from a xml file. The [TestMethod] attribute is pushed to the back of the new attribute set:





Here’s the bit that got chopped off:DataDrivenTest02and the code for this test.

The position of this TestData.xml in the solution:



And the content of TestData,xml:


The xml.

Run the test – we expect the 24,37 combination to be executed, then the -5,-2 combination. What actually happened was that the first one passed, but the second failed:


Why? Because the Page Object does not know how to handle the minus operator. The call:


… which calls…


That is crying out anyway for some refactoring of the Dom filtering, but that aside, let’s at least have a stab at handling signed integers… in fact forget it – I’ve just established that this web calculator is pretty broken when it comes to a deterministic way of handling negative signs (whereas the plus signs we can just throw away as the default). So I won’t waste any more energy on this one. What have I proven?

  • It’s easy to data drive in fact not just CodedUI tests, but any test that is a MSTest, and presumably a variation would work for other unit test frameworks.
  • Adding different data to the tests might reveal defects in the test itself… or in the Application Under Test, but maybe the AUT was designed / specced deliberately like that. I can’t know.






Coded UI: test of an HTML calculator using the same Test

The title is not strictly true, in that I had a new Page Object to handle a public domain web-based calculator. Doing this emphasised  that in changing technologies to achieve the same functionality, the design may change… and actually affect the behaviour of the test. In this case, in the Window Forms version, I had a dedicated read-only box for the answer, but in the public html version (one I just picked from the internet, not one I wrote), one box services  the entry of the first number, the second number, and the presentation of the answer. That means a) the Page Object contract changes, meaning that b) its Test client has to change. Well, to be more precise the HTML Page Object differs from the Forms Page Object in behaviour, although it implements the same functionality. In fact using this web based calculator actually shows a defect in the functionality, I suggest: in my tests, I have 24 and 37 as the two input integers with 61 as the answer. That’s fine for the Forms test, but for the Web test, the actual answer is [space][space]61[dot]. So the Test is doing its job in that it is unaware of what technology is at play, and the Page Object is doing its job in abstracting away the technology.

For now, this is the Test, where I have edited the existing test for the new behaviour (I suggest that at any one time you would not have 2 versions of the test, you would switch over one day e.g. from Forms to HTML, so that approach is valid). However, it does bring into relief the poor naming of the Test class, i.e. WindowsFormsControlsTest: whatever it is, it should not mention the technology, as it is not aware of it. Well, maybe… at some point you have to give the SUT the context. Anyway the test…



And the Page Object between the code and the test:




Code for the test.

Code for the page object.



Coded UI: AButtonIsClickedAndTextisEnteredInAnEditControl

A trivial and yet major step on for the Windows Forms Coded UI for me. While the code generator may be pointless for production given its output is totally unmaintainable, it is very useful for understanding the hierarchy of the controls. Only doing this have I realised that in the simplest of applications, you have an outer container, and then for each “usable” control, you have a control between the outer container and the usable control:


This is the trivial thing this was based on… I don’t think code is needed for this:



, and the code itself.

Coded UI: WinForms applications

I’ll gloss over the “Why” of this…

Doing it (testing against WinForms applications) nonetheless reinforces the point that these are just implementations of Page Objects.

Frustrating point of the day: the lack of obvious correspondence between the properties exposed in the WinForms / C# editor for a given control, and what is exposed by the Coded UI Test Builder and SearchProperties collection in .Net / C#. I was going to do an example, and I shall regret not doing it as I shall forget the case.

Take this:


Firstly, I had to change the “*” in the original to “mult”, as it appears that without escaping (I’m guessing) then “*” is not recognised or mis-translated. That aside, this is what WinForms says about it (I picked the app up from some msdn place, hence the misspelling):



So based on this, the Name is either btnMulitply or there is no name, or it’s the parent object. Note that Text is “mult”.

Now the code finds flaming “mult” as Name… which is quite frustrating. And as for the Edit control, well, there isn’t ANY way that I can see to uniquely identify that.

But at least the weekend yielded a good find in the form of the Page Object implementation on CodePlex. I still can’t work out if this is Microsoft work, given the Namespace.

Oh, there is this good thing as well, which identifies all the objects on your desktop.

This data driven attribute was a nice find as well:

Calc04 Calc05