Budowanie aplikacji w dowolnej technologii z wykorzystaniem techniki TDD ( ang. test driven development), czyli w skrócie rozwijania kodu poprzez pisanie niedziałających testów, doprowadzenie kodu, by testy działały i aplikacja realizowała daną funkcję, a następnie refaktorowanie kodu aplikacji oraz testów, pozwala implementować rozwiązania posiadające mniej błędów. Jakich narzędzi i bibliotek warto użyć do testowania ?
W zależności od rodzaju testów (jednostkowych, integracyjnych, E2E), można dla każdej z technologi, w której budujemy aplikacji, znaleźć bardzo dużą liczbę narzędzi i bibliotek do testowania, dlatego poniższa lista z pewnością nie jest kompletna, ale zawiera kilka przykładów tego, czego często można spotkać.
Narzędzia Link to heading
- Selenium - jeden z najbardziej znanych narzędzi do testowania aplikacji webowych poprzez symulowanie akcji wykonywanych przez użytkownika w przeglądarce internetowej
 - Appium - narzędzie do testowania nie tylko apliakcji webowych, lecz również mobilnych
 - Robot Framework - potężny kombajn do budowania testów różnorodnych aplikacji, posiadający wiele bibliotek np. do baz danych, platform mobilnych czy nawet protokołów sieciowych jak telnet. Poniżej przykład testu:
 
*** Settings ***
Documentation     A test suite with a single test for valid login.
...
...               This test has a workflow that is created using keywords in
...               the imported resource file.
Resource          resource.txt
*** Test Cases ***
Valid Login
    Open Browser To Login Page
    Input Username    demo
    Input Password    mode
    Submit Credentials
    Welcome Page Should Be Open
    [Teardown]    Close Browser
Biblioteki Link to heading
- 
Spock - pozwala na pisanie testów w formacie given-when-then, albo expect-where, wprowadzając dużo większą przejrzystość i utrzymywalność.
 - 
TestNG - dostarcza wiele adnotacji, pozwala na dużo większą elastyczność niż JUnit4, a czasem nawet większą czytelność niż JUnit5.
 - 
AssertJ - pozwala na pisanie testów w sposób ciągły:
assertThat(xmlFile).exists(); assertThat(contentOf(xmlFile)).startsWith("<?xml version="); - 
Gherkin language - składnia wykorzystywana np. w Cucumber w technice BDD ( ang. behaviour driven development)
 - 
REST Assured, WireMock - narzędzia do testowania REST API w Javie
 - 
Mockito - jeden z najpopularniejszych w Javie narzędzi do mockowania
 - 
Spring Cloud Contract, Pact - jedne z najpopularnieszych w świecie Javy, ale nie tylko, rozwiązania do testów kontraktowych.
 
Przykłady kodu Link to heading
Ucząc się testowania aplikacji na publicznych repozytoriach GitHub umieściłem 3 aplikacje:
- FizzBuzz - kod, w którym oprócz zwykłych testów jednostkowych, zbudowałem kilka testów parametryzowanych oraz wykorzystujących Spock’a,
 - BonusCalculator - kod budowany technika TDD z testami w JUnit,
 - SnowMocksKata - aplikacja mająca testy wykorzystujące Mockito.
 
Przykładowo testy parametryzowane można budować jak niżej:
@ParameterizedTest
@ValueSource(ints = { 25, 65, 55 })
public void should_return_fizz_when_many_inputs_is_dividable_by_5(int number) {
String fizzBuzzResult = fizzBuzz.fizzBuzz(number);
assertThat(fizzBuzzResult).isEqualTo("Fizz");
}
Z kolei pisanie specyfikacji i testy w Spock’u mogą wyglądać następująco:
class FizzBuzzSpecification extends Specification {
def "should return number when input is 1"() {
given:
def fizzBuzz = new FizzBuzz()
when:
def fizzBuzzResult = fizzBuzz.fizzBuzz(1);
then:
fizzBuzzResult == "1"
}
def "should return buzz is when input is dividable by 7"(int input, String output) {
given:
def fizzBuzz = new FizzBuzz()
expect:
output == fizzBuzz.fizzBuzz(input)
where:
input | output
21 | "Buzz"
14 | "Buzz"
49 | "Buzz"
}
}
Podsumowanie Link to heading
Niezależnie od technologii budowania aplikacji, warto ją testować na każdym poziomie piramidy testowania, dlatego część wymienionych narzędzie może kogoś zainspiruje do sięgnięcia po niektóre z nich.