Coded UI Tests - cz. 2

Podstawy Coded UI Test zostały omówione w poprzednim poście tego bloga tutaj, jednak warto rozwinąć ten temat i trochę usystematyzować wiedzę. W tym poście zakładam, że każdy wie jak stworzyć prosty test oraz czym jest Coded UI Test Builder. Zacznijmy od tego że aby nasze testy przechodziły musimy odpalić instancję testowanej aplikacji :). Możemy oczywiście robić to za każdym razem ręcznie, jednak jest to skrajnie beznadziejne rozwiązanie. Najlepiej przygotować sobie metodę, która będzie odpalać instancję naszej aplikacji jeżeli nie jest ona uruchomiona.

Ok przyjrzyjmy się strukturze plików i sposobowi budowania testów. Przede wszystkim do projektu testowego możemy dodać 2 obiekty. Pierwszy to "Coded UI Test" (CUIT) - czyli klasa opatrzona atrybutem [CodedUITest]. Jest to nasza właściwa klasa testowa. Tutaj właśnie tworzymy nasze testy. Drugi obiekt to klasa "Coded UI Test Map". Nie musimy jej dodawać ręcznie (poprzez Add->New Item...->Coded UI Test Map), bo zostanie ona stworzona automatycznie jeżeli wygenerujemy kod przy pomocy Coded UI Test Builder'a. Wszystkie wygenerowane przez nas akcje i asserty zapisywane są w takiej Mapie. Tworząc CUIT tak naprawde odwołujemy się do wygenerowanego kodu znajdującego się w mapie. W dużych aplikacjach modułowych powinniśmy używać wielu map, gdzie każda reprezentuje inny moduł.
Dla każdej wygenerowanej metody tworzona jest klasa, której instancja przechowuje wartości oczekiwane lub wprowadzane przez użytkownika. Dzięki temu mamy możliwość manipulacji warunkami dla każdej akcji. Instancja każdej z takich klas wystawiona jest jako właściwość w obiekcie naszej mapy.

Jak pisać testy? Jest to bardzo dobre pytanie. Przede wszystkim każdy CUIT opiera się na metodach które wygenerujemy. Każda wygenerowana metoda to akcja którą nagraliśmy za pomocą Coded UI Test Builder. Czyli powinniśmy nagrywać możliwie krótkie akcje, dzięki czemu możemy później kombinować je ze sobą tworząc wiele testów opartych na pojedyńczych akcjach. Wówczas jeżeli zmieni się coś w interfejsie użytkownika np zwykły button zostanie zastąpiony przez kontrolke innego typu, wówczas nie musimy nagrywać ponownie wszystkich testów które korzystały z danego buttona. Wystarczy wygenerować od nowa metode "WcisnijButton" i ewentualnie zmienić jej nazwę na inną (co jest standardową czynnością, którą można błyskawicznie wykonać). Mówiąc bardziej ogólnie: Nie powinno się utożsamiać CUIT z nagraną akcją dostępną w UIMap. CUIT powinien składać się z wielu uniwersalnych akcji nagranych przez użytkownika. Takimi pojedynczymi akcjami mogą być:
-kliknięcie przycisku
-sprawdzenie że kontrolka przyjęła odpowiedni stan
-wprowadzenie textu do TextBoxa
itd.

Ok przykład. Mamy aplikacje napisaną w WPF. Nie wnikamy w jej sens. użytkownik ma do dyspozycji 2 TextBox'y oraz TextBlock. W TextBlock'u wyświetlamy złączone napisy wprowadzone do TextBoxów. Kod aplikacji wygląda mniej więcej tak:

<Window x:Class="WpfApplication3.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <StackPanel>
        <TextBox Name="TextBox1"/>
        <TextBox Name="TextBox2"/>
        <TextBlock Name="TextBlock">
            <TextBlock.Text>
                <MultiBinding StringFormat="{}{0}{1}">
                    <Binding Path="Text" ElementName="TextBox1"/>
                    <Binding Path="Text" ElementName="TextBox2"/>
                </MultiBinding>
            </TextBlock.Text>
        </TextBlock>
    </StackPanel>
</Window>

Chcemy przetestować czy TextBlock rzeczywiście wyświetla złączone napisy z TextBoxów. Tworzymy zatem klasę testową. Następnie generujemy akcje wpisywania tekstu do TextBox1 oraz akcje wpisywania textu do TextBox2. Tworzymy metodę (assert), która porównuje czy w TextBocku jest wpisany "CustomText". Ok czyli w rezultacie mamy 3 metody. Wpisany text do textboxów został przez nas skonkretyzowany podczas nagrywania akcji (dla przykładu można przyjąć że jest to "Custom Text"). Możemy teraz przetestować czy napis w TextBlock jest prawidłowy. Musimy podmienić text który jest testowany. Można to zrobić za pomocą klas parametrów tworzonych automatycznie podczas generowania kodu.

[TestMethod]
public void CodedUITestMethod1()
{
    // Arrange
    Just.EnterTextIntoTextBox1Params.UITextBox1EditText = "Coded";
    Just.EnterTextIntoTextBox2Params.UITextBox2EditText = "UI";
    Just.VerifyTextBlockTextExpectedValues.UITextBlockTextDisplayText = "CodedUI";
    // Act
    Just.EnterTextIntoTextBox1();
    Just.EnterTextIntoTextBox2();
    // Assert
    Just.VerifyTextBlockText();
}

W powyższym przykładzie zmieniłem domyślną nazwę UIMap na Just.
Teraz wyobraźmy sobie że chcemy zrobić testy seryjne. Mamy np całą tabelę z danymi i chcielibyśmy ją "wstrzyknąć" do naszego testu razem z wynikami. Nic prostrzego. W tym wypadku możemy zastosowac dokładnie ten sam mechanizm, który znamy z Unit Testów czyli DataSource.
Najpierw musimy dodać do klasy testowej CUIT właściwość TestContext:

private TestContext testContextInstance;
public TestContext TestContext
{
    get { return testContextInstance; }
    set { testContextInstance = value; }
}

Instancja klasy TestContext zostanie stworzona automatycznie po uruchomieniu naszych testów, dlatego bez problemu możemy się odwoływac do tej właściwości w naszych metodach testowych.
Aby stworzyć testy seryjne musimy dodać atrybut DataSource do naszej metody testowej. Atrybut ten wskazuje źródło danych, które są dostępne za pomocą właściwości TestContext. Teraz nasz test wykona się dla wszystkich wartości jakie znajdują się w naszym źródle danych. Plik z danymi podpinamy do projektu testowego. Klikamy na niego PPM wybieramy właściwości i ustawiamy "Build Action" na "Content" oraz "Copy to Output Directory" na "Copy if newer".
Plik "Data.csv"

Input1,Input2,ExpectedResult
a,b,ab
one,two,onetwo
, ,

kod:

[DeploymentItem("Tests\\Data.csv"),
DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV","|DataDirectory|\\Data.csv", "Data#csv",DataAccessMethod.Sequential),
TestMethod]
public void CodedUITestMethod1()
{
    // Arrange
    Just.EnterTextIntoTextBox1Params.UITextBox1EditText = TestContext.DataRow["Input1"].ToString();
    Just.EnterTextIntoTextBox2Params.UITextBox2EditText = TestContext.DataRow["Input2"].ToString();
    Just.VerifyTextBlockTextExpectedValues.UITextBlockTextDisplayText = TestContext.DataRow["ExpectedResult"].ToString();
    // Act
    Just.EnterTextIntoTextBox1();
    Just.EnterTextIntoTextBox2();
    // Assert
    Just.VerifyTextBlockText();
}

Posted in: Coded UI,Test,UIAutomation,Visual Studio 2010 Ultimate,WPF