Co z tą asercją?

Prelegent: Agnieszka Kościuczyk
W swojej pracy zawodowej spotkałam się z różnymi podejściami do asercji – część osób tworzących automaty upiera się, że zgodnie ze starą szkołą unit testów powinno się mieć jedną asercję na test, na poziomie samego testu. Z drugiej strony jednak w przypadku, gdy mamy zautomatyzować dużą aplikację, gdzie nie możemy pozwolić sobie na przerwanie kodu po pierwszej asercji, musimy umieścić ich więcej. Równocześnie bardzo dużo osób ma też problemy z wyszczególnieniem co dokładnie powinno być sprawdzane w czasie testu i jak ważne jest to dla jego wyniku.
W czasie swojej prezentacji przedstawię na przykładach z automatyzacji testów dużych aplikacji webowych, jak najlepiej według mnie potraktować asercje. Dodatkowo powiem o tym jak powinien wyglądać kod, aby był prosty do utrzymania i aby osoba posługująca się nim była w stanie w łatwy sposób używać go z wykorzystaniem fluent interfaces.

    • W bardziej szczegółowy sposób zajmę się zagadnieniami takimi jak:

    • Czym jest asercja?

W tym punkcie przedstawię definicję asercji oraz opowiem o głównych założeniach z nią związanych.

    • Różnica pomiędzy asercją w testach unitowych a funkcjonalnych

Istnieje różnica pomiędzy sprawdzaniem poprawności kodu składającego się z kilku/kilkunastu linii, a kodu, który składa się na daną funkcjonalność w systemie (chociażby najprostsze rzeczy typu logowanie do systemu) – czy w takim razie w obu przypadkach powinniśmy tak samo stosować asercję?

    • Czym są fluent interfaces?

W powyższym punkcie przedstawię definicję i założenia fluent interfaces oraz przedstawię ich wykorzystanie w testach automatycznych. Podkreślę również zysk, jaki mamy z ich wykorzystania – głównie w trakcie pisania kodu i jego wykorzystywania.

    • Jak to czasem wygląda?

W swojej codziennej pracy spotykam się z różnymi wykorzystaniami asercji w testach. Nie zawsze są to podejścia sensowne – zaprezentuję parę przykładów, które pokażą, jak w łatwy sposób utrudnić sobie zarządzanie kodem i wprowadzanie do niego zmian tylko dzięki temu, że asercje mamy widoczne na poziomie testu.

    • Jak to może wyglądać?

Jak w poprzednim punkcie na przykładach pokażę wypracowane przez siebie podejście do asercji oraz opowiem, jak ułatwiło mi ono pracę z kodem.

    • Czy wszystko powinno kończyć się failem?

Czy na pewno powinniśmy przerwać wykonywanie kodu przy najmniejszym błędzie będącym nawet literówką w wyświetlonym komunikacie na stronie? Czy powinniśmy sprawdzać każdy najdrobniejszy szczegół czy tylko najważniejsze elementy? Na koniec postaram się odpowiedzieć na zadane powyżej pytania.

 


Tagged under:

Program konferencji

TwitterFacebookLinkedInGoogle+