Saturday, 29 March 2014

Execute Coded UI Test with Console Application

Can a Coded UI test executed with  a Console Application? Yes it is possible. I am going to explain how it can be done.

I am going to execute below simple hand written Coded UI test to launch a notepad, using a Console Application.

Create Console Application in VS 2012. Refer the Coded UI in the Console Application. Then add below references to below assemblies.

from C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\

from C:\Program Files (x86)\Common Files\microsoft shared\VSTT\11.0\

from C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\

Then add below code to Console Application

This Console Application now can run Coded UI test.

Thursday, 20 March 2014

Writing Better Coded UI Test?

Yesterday I asked from my colleagues how to optimize a Coded UI test that I have written to run an InstallSheild wizard. No one replied to me, so I decided to investigate on my own.

OK here is the code I have in my Coded UI test which runs for 25 seconds (Installsheild wizard only consumes bout 6-7 seconds).



        WinWindow wizard = new WinWindow();
        wizard.SearchProperties.Add(WinWindow.PropertyNames.Name, "My App - InstallSheild Wizard");

        WinButton next = new WinButton(wizard);
        next.SearchProperties.Add(WinButton.PropertyNames.ControlType, "Button", WinButton.PropertyNames.Name, "Next >");


Here is the test execution time and the detail log

It takes lot of time to detect the "Next"  button (21 Seconds).

With some trial and error below code did the best



        WinWindow wizard = new WinWindow();
        wizard.SearchProperties.Add(WinWindow.PropertyNames.ClassName, "MsiDialogCloseClass");

        WinButton next = new WinButton(wizard);
        next.SearchProperties.Add(WinButton.PropertyNames.ControlType, "Button", WinButton.PropertyNames.Name, "Next >");

The change to ClassName did the trick.

wizard.SearchProperties.Add(WinWindow.PropertyNames.ClassName, "MsiDialogCloseClass");

Now finding "Next"  button with 6 seconds (Installer initial running time)

With much better code using a great extension class for Coded UI by Kris Lankford

 // Launch the InstallShield wizard
            var setup = ApplicationUnderTest.Launch(@"C:\Deploy\Install\DiskImages\DISK1\setup.exe");

            // Find the wizard
            WinWindow wizard = setup.Container.SearchFor(new { ClassName = "MsiDialogCloseClass" });

            // Click on Next button in first step
            Mouse.Click(wizard.SearchFor(new { Name = "Next >" }));
managed to hit 8 seconds. Wow! 3 times faster than original ... way to go!

Monday, 10 March 2014

TFS Build - SharePoint Projects - Assembly Versioning

Just thought of sharing my experience last week with SharePoint 2013 projects built with TFS.

The Requirement

Create a QA Build (to do releases to QA) for a solution with SharePoints projects. Version number of each assembly must be changed as specified below.(How to version number change with TFS is here)

Version number should be in x.x.x.x format and last number should increment by one in each QA build. Example if first version build assembly version number is then in second it should be (I used my own build template to do this but you can do this as described here)

All went well and my TFS Build created necessary .wsp files in build drop.


Where it went wrong?

When .wsp files deployed to SharePoint it deployed, but creating a site collection utilizing .wsp files gave famous "Something went wrong" SharePoint error. One sleepless night to diagnose the issue with no luck with my little knowledge in SharePoint (believe me it was a huge SharePoint product I was dealing with and I do not still have a clue how share point works :) , I was doing only my part use TFS and get a build working )

Tried with a build without changing version number and all went well. huh! then this is about version numbers? Had a good look at that "Something went wrong" page. Aha..In url it had some mentioning cannot load assembly with reflection.

What was the solution?

Simply modified my build template to change only AssemblyFileVersion without touching AssemblyVersion. It did the trick and I could successfully deploy the .wsp s built with TFS - version number changed (only AssemblyFileVersion), and use them in a SharePoint site creation.

Further investigation to code base lead to find the culprit. It was SharePoint Feature, ReceiverAssembly syntax. The experts in SharePoint told me it is the way it is, and they did not like my idea of TFS Build manipulating these files to change version number here as well :( . (My ideal solution)