owenG
Deviceful Doings
home about
divider
SDLC VS 2010 Coded UI Test Coded UI Test and Fitnesse MSBuild 4.0 MSBuild and IronPython MSBuild and IronPython - TFS checkins MSBuild and IronPython - Custom SQL Data








previous next

Coded UI Test and Fitnesse Part 1

May 2010

Coded UI is a new feature of Visual Studio 2010 that allows for UI automation à la Selenium, SilkTest, QTP etc. It fully integrates with the Application Lifecycle Management elements of Visual Studio 2010, with the bonus of being able to customize the automation using C# or VB.Net. My page over here runs through a simple example in order to explore some of the details.

Fitnesse is "a simple tool that allows non-technical users to specify and run acceptance tests for software systems". In the agile testing pyramid concept, unit tests would be at the base and UI automation, like Coded UI Testing, at the top. A tool like Fitnesse can help with the middle layer, the realm of functional and acceptance tests - think something along the lines of high-level unit tests for the business side. There are tools like Selenesse that can help integrate Selenium with Fitnesse but Microsoft's Coded UI Test (CUIT) generally does not want to be run outside of the ALM framework. This article presents one possibility to enable low-level integration between CUIT and Fitnesse.

divider element

Overview

Use Fitnesse to a) provide the source data for a data-driven Coded UI Test and, b) automate kickoff of the CUIT.


Setting up Fitnesse

I won't go into any real detail on the setting up of Fitnesse since there are already a number of tutorials. The one at Rapid Intro to using Slim with .Net is particularly apt since it involves Slim (Simple List Invocation Method). Slim is an alternative to using Fit, with the one major benefit being how easy it can be to set up a simple test. The examples below expect the fitSharp binaries to be located in a folder named Slim1.6, at a sibling level to main FitNesseRoot directory. As indicated by the naming convention, the version of fitSharp I'm using is 1.6, which happens to be the latest available from http://github.com/jediwhale/fitsharp/downloads as of this writing.

fitsharp 1.6

Fitnesse Test Configuration

On the Front Page of the Fitnesse Wiki I Edit the markup text, adding a camel-cased test description: StringManipulationTest. Save the page, click the '?' hyperlink next to the newly entered text

Fitnesse FrontPage with new link

and a new StringManipulationTest wiki page is ready to be created under FitnesseRoot:

StringManipulationTest page ready to create

Leave the default content and add some text relevant to this test:

wiki
    !define TEST_SYSTEM {slim}
    !define COMMAND_PATTERN {%m -r fitSharp.Slim.Service.Runner,slim1.6\fitsharp.dll %p}
    !define TEST_RUNNER {slim1.6\Runner.exe}
    !path C:\owenG\projects\full_path_to_my_DLL.dll
    
    |import|
    |test_dll_namespace|

where the TEST_SYSTEM indicates we are using slim instead of the default fit framework. The !path holds a dummy value right now, which will need to be updated once there is a test project in Visual Studio. Same as to the namespace to be imported. Save the page and put off to the side for now. Note that because the name I gave the page ended in the text "Test" (StringManipulationTest), Fitnesse knew I was creating a test page. Otherwise, I would have needed to click Properties link on the page's left-hand menu -> set Page type to 'Test' -> and Save Properties in order for the top link to read "Test" instead of "Edit".

Classy

Now onto the .net dll that will serve as the system under test. Normally this would consist of lightweight code that serves only as an entry point to the existing classes and 'real' code to be tested. For this sample though the entirety of the implementation will be in the test .dll, albeit in a separate class. Simply makes it easier to illustrate. Either way, I create a new Blank Solution named FitnesseTestHarness, located in C:\owenG\projects. Right-click on the solution in Solution Explorer and add a new project, of type = C# Class Library. Since I'm using Visual Studio 2010 and the fitSharp dll's were built on the 3.5 framework, need to make sure the Target Framework on the new project is set to .Net Framework 3.5 before naming it fitsharpStringTests. Rename the .cs file to StringManipulatorAndTests.cs, since it will serve dual purposes. Rename the default class to StringManipulator and prepare to implement as a static class:

empty StringManipulator class

Now to populate, where we want it to perform a few different types of string operations:

C#
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
              
    namespace fitsharpStringTests
    {
        public static class StringManipulator
        {
            public static string ConcatenateStringsAndKeepOrdinality(string one, string two)
            {
                return one + two;
            }

            public static string SwapStringOrdinalityAndConcatenate(string one, string two)
            {
                return two + one;
            }

            public static string RevCharFirstStringAndConcatenate(string one, string two)
            {
                char[] letters = one.ToArray();
                Array.Reverse(letters);
                string reversed = new string(letters);
                return reversed + two;
            }
        }
    } 

Now add a second class in fitsharpStringTests namesapce, will hold the code to be accessed by Fitnesse/fitSharp:

C#
    public class StringManipulatorTests
    {
        string _firstString = "";
        string _secondString = "";

        public void SetFirstPieceOfText(string first)
        {
            _firstString = first;
        }

        public void SetSecondPieceOfText(string second)
        {
            _secondString = second;
        }

        public string JoinTextTogether()
        {
            return StringManipulator.ConcatenateStringsAndKeepOrdinality(_firstString,  _secondString);
        }

        public string SwapTextOrderAndJoin()
        {
            return StringManipulator.SwapStringOrdinalityAndConcatenate(_firstString,  _secondString);
        }

        public string ReverseLettersInFirstPieceOfTextAndJoin()
        {
            return StringManipulator.RevCharFirstStringAndConcatenate(_firstString, _secondString);
        }
    } 

A couple of things to note:

  • The Set prefix on the SetFirstPieceOfText and SetSecondPieceOfText is prescribed, where remaining text in the method names will be specified on the Fitnesse side e.g SetFirstPieceOfText will be run by a FirstPieceOfText (or actually "First Piece Of Text") marker in the wiki markup
    • in fact, could have used same-named Properties instead of Set* methods, or private fields (w/ or w/o a leading underscore, fitSharp will figure it out)
    • Those methods, and the ones that represent the test oracle, (JoinTextTogether, SwapTextOrderAndJoin, and ReverseLettersInFirstPieceOfTextAndJoin) are purposefully written in a more user/business friendly manner. The person writing the tests on the Fitnesse side may not even know what a string is, and Join may be a better term than Concatenate (or not, just depends on the scenario).

There will be additional C# code to add later but for now...

Next, Filling out Fitnesse

previous next