Testy aplikacji na egzaminie INF.04: przypadki testowe, dane graniczne i testy jednostkowe

Słowo „test” znaczy w arkuszach INF.04 trzy różne rzeczy:

• test w programie głównym - wywołanie funkcji lub metod klasy i wypisanie wyniku w konsoli. Tak jest w INF.04-02-22.06-SG (kolejne konstruktory klasy i licznik obiektów), INF.04-03-23.06-SG (test metod set, get i inkrementacji „przed i po”), INF.04-02-24.01-SG („przetestować obie metody”), INF.04-02-25.01-SG („z wartościami poprawnymi i niepoprawnymi”) i INF.04-02-26.01-SG (próba utworzenia obiektu, która ma się nie skompilować),
• test w osobnym pliku - INF.04-02-23.06-SG: fragment programu głównego sprawdzający sortowanie liczb pseudolosowych z przedziału 0..1000, zapisany w folderze testy w pliku test „z rozszerzeniem charakterystycznym” dla języka i udokumentowany zrzutem konsola_testy.jpg,
• testy jednostkowe z biblioteką testową - INF.04-02-25.06-SG (szyfr Cezara, 5 przypadków z tabeli) i INF.04-01-26.01-SG (rzut kością, 2 przypadki).

W INF.04-02-22.06-SG, INF.04-02-23.06-SG, INF.04-02-25.06-SG, INF.04-01-26.01-SG i INF.04-02-26.01-SG testy są osobnym, czwartym rezultatem oceny.

Arkusze INF.04-02-25.06-SG i INF.04-01-26.01-SG stawiają te same warunki:

• biblioteka do testów jednostkowych dostępna na stanowisku, dla języka, w którym napisano aplikację konsolową,
• nazwy metod testujących „wyrażają cel danego testu” i są zapisane „zgodnie z konwencją nazewnictwa w danym języku programowania”,
• każdy przypadek testowy - oddzielną metodą, sprawdzaną asercją,
• metody testujące w oddzielnym pliku, „w lokalizacji zgodnej z wymaganiami” języka i biblioteki (INF.04-02-25.06-SG),
• uruchom wszystkie metody i zrób zrzuty test1.png, test2.png... w folderze testy, z widocznymi wynikami, całym ekranem, paskiem zadań i środowiskiem programistycznym.

INF.04-02-25.06-SG dodaje: „Jeżeli metoda szyfrująca została napisana w części I niepoprawnie, testy powinny wykazać błędy. W tej części egzaminu ocenie podlegać będzie zapis i uruchomienie testu, a nie metoda szyfrująca”.

Przypadek testowy to trzy rzeczy: co sprawdzasz, z jakimi danymi i jaki wynik jest poprawny. Tak zbudowana jest tabela 4 z INF.04-02-25.06-SG („Scenariusz testowania z przypadkami testowymi”):

Klucz oceny ma po jednym kryterium na każdy z tych pięciu testów (R.4.3-R.4.7), np. „Zapisany test jednostkowy 2, który przy danych wejściowych xyz, 3 oczekuje wyniku abc”. Dane i wynik przepisz z tabeli bez zmian.

Gdy arkusz nie podaje tabeli, dobierz dane sam - z trzech grup. Przykład: funkcja sprawdzająca liczbę kości, która ma być z zakresu 3-10:

• poprawne, typowe - wartość ze środka zakresu, np. 5,
• graniczne - same granice (3 i 10) i wartości tuż za nimi (2 i 11). Tu najczęściej siedzą błędy, np. > zamiast >=,
• błędne - wartości bez sensu dla programu: 0, liczba ujemna, tekst zamiast liczby.

Tak samo myśli egzaminator: klucz INF.04-01-24.06-SG każe sprawdzić pętlę pytającą o liczbę kostek „dla granicznych: 2 i 11 oraz 3 i 10”. Arkusz INF.04-02-25.06-SG chce zrzutów „dla różnych wartości klucza (0, ujemna, dodatnia)”, a INF.04-02-25.01-SG - testu „z wartościami poprawnymi i niepoprawnymi”.

Zanim napiszesz kod testów, rozpisz przypadki tak jak w tabeli z arkusza - to plan, z którego od razu wynikają nazwy metod testujących:

Arkusze nie każą zapisywać takiej tabeli w pliku egzamin - podają ją same (INF.04-02-25.06-SG) albo wymieniają przypadki w punktach (INF.04-01-26.01-SG). Rozpisanie przypadków na brudno pilnuje, żeby żadnego nie pominąć.

Program z przykładu pyta o liczbę kości tak długo, aż dostanie liczbę z zakresu 3-10. Uruchom go i wpisz dane z każdej grupy: 2 (tuż poniżej), 11 (tuż powyżej), abc (tekst) i na końcu 10 (granica). Program trzy razy ponawia pytanie, a po 10 rzuca dziesięcioma kośćmi i podaje sumę.

Ten zrzut dokumentuje „interakcje”, o które pytają arkusze - tu konsola z Visual Studio w tle. Arkusze z testem w programie głównym (np. INF.04-03-23.06-SG) oceniają właśnie wynik widoczny na ekranie: „wyświetlona jest wartość pola przed i po zastosowaniu metody”.

Test w programie głównym to wywołanie i czytelny komunikat z wynikiem. Wzór „przed i po”, którego wymaga INF.04-03-23.06-SG, w przykładzie z kośćmi:

int[] wyniki = { 2, 3, 4 };
Console.WriteLine("Test sumy: oczekiwano 9, otrzymano " + RzutKoscmi.Suma(wyniki));
Console.WriteLine("Test granicy 3: " + RzutKoscmi.CzyPoprawnaLiczbaKosci(3));
Console.WriteLine("Test liczby 11: " + RzutKoscmi.CzyPoprawnaLiczbaKosci(11));

Komunikat mówi, co jest sprawdzane i jaki wynik wyszedł - kryterium „komunikacja z użytkownikiem prowadzona jest w sposób zrozumiały” (R.1.7) dotyczy też testów.

W Visual Studio testy jednostkowe C# są osobnym projektem w tym samym rozwiązaniu. Kliknij rozwiązanie prawym przyciskiem w Eksploratorze rozwiązań, wybierz Dodaj → Nowy projekt…, wpisz w wyszukiwarce MSTest i wybierz szablon projektu testowego MSTest dla C#. Nazwij projekt np. KosciTesty.

W projekcie testów kliknij prawym przyciskiem Dodaj → Odwołanie do projektu… i zaznacz projekt aplikacji konsolowej - bez tego testy nie widzą jej klas. Na zrzucie rozwiązanie z dwoma projektami: Kosci (aplikacja) i KosciTesty (testy), otwarty plik RzutKoscmiTesty.cs z metodami testującymi.

Każdy wiersz tabeli przypadków to jedna metoda z atrybutem [TestMethod] i jedną asercją:

using Kosci;

namespace KosciTesty
{
    [TestClass]
    public sealed class RzutKoscmiTesty
    {
        [TestMethod]
        public void DolnaGranicaTrzyJestPoprawna()
        {
            Assert.IsTrue(RzutKoscmi.CzyPoprawnaLiczbaKosci(3));
        }

        [TestMethod]
        public void DwaPonizejZakresuJestNiepoprawne()
        {
            Assert.IsFalse(RzutKoscmi.CzyPoprawnaLiczbaKosci(2));
        }

        [TestMethod]
        public void SumaTrzechKosci()
        {
            Assert.AreEqual(9, RzutKoscmi.Suma(new int[] { 2, 3, 4 }));
        }
    }
}

Assert.AreEqual(oczekiwana, otrzymana) porównuje wartość oczekiwaną z wartością zwróconą przez funkcję - dokładnie to, czego wymaga kryterium „metoda testująca porównuje wartość oczekiwaną z wartością zwracaną”. Nazwy w stylu PascalCase to konwencja C#.

Wybierz Test → Uruchom wszystkie testy (skrót Ctrl+R, A). Wyniki pokazuje Eksplorator testów.

Na zrzucie funkcja ma celowo wprowadzony błąd: liczba > 3 zamiast liczba >= 3. Test DolnaGranicaTrzyJestPoprawna jest czerwony, a w szczegółach widać, która asercja zawiodła. Pozostałe testy przechodzą - błąd wyłapał tylko test na granicy.

Po poprawce liczba >= 3 wszystkie testy są zielone. Zrób zrzut całego ekranu z Eksploratorem testów, kodem i paskiem zadań (Win+PrtScn) i zapisz go jako test1.png w folderze testy. Przy wielu testach rozwiń listę tak, żeby była widoczna każda metoda - albo zrób kolejne zrzuty test2.png, test3.png.

W Pythonie biblioteka unittest jest wbudowana. Testy zapisz w osobnym pliku, np. test_kosci.py, obok pliku z funkcjami:

import unittest
from kosci import czy_poprawna_liczba_kosci, suma, rzuc


class TestKosci(unittest.TestCase):

    def test_liczba_w_srodku_zakresu_jest_poprawna(self):
        self.assertTrue(czy_poprawna_liczba_kosci(5))

    def test_dolna_granica_trzy_jest_poprawna(self):
        self.assertTrue(czy_poprawna_liczba_kosci(3))

    def test_dwa_ponizej_zakresu_jest_niepoprawne(self):
        self.assertFalse(czy_poprawna_liczba_kosci(2))

    def test_suma_trzech_kosci(self):
        self.assertEqual(9, suma([2, 3, 4]))

    def test_kazdy_rzut_jest_z_zakresu_1_do_6(self):
        for wynik in rzuc(1000):
            self.assertTrue(1 <= wynik <= 6)


if __name__ == "__main__":
    unittest.main()

Nazwy metod zaczynają się od test_ - po tym unittest je rozpoznaje - i są pisane małymi literami z podkreślnikami, zgodnie z konwencją Pythona. Uruchomienie: python -m unittest -v w folderze projektu albo uruchomienie pliku z testami w środowisku programistycznym.

W Javie typowa jest biblioteka JUnit 5 - metoda testująca ma adnotację @Test, a asercje pochodzą z klasy Assertions:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class KosciTest {

    @Test
    void liczbaWSrodkuZakresuJestPoprawna() {
        assertTrue(Kosci.czyPoprawnaLiczbaKosci(5));
    }

    @Test
    void dolnaGranicaTrzyJestPoprawna() {
        assertTrue(Kosci.czyPoprawnaLiczbaKosci(3));
    }

    @Test
    void dwaPonizejZakresuJestNiepoprawne() {
        assertFalse(Kosci.czyPoprawnaLiczbaKosci(2));
    }
}

Nazwy metod w Javie zapisuje się w stylu camelCase. W C++ Visual Studio z obsługą C++ ma szablon projektu testów natywnych (Native Unit Test Project, biblioteka Microsoft C++ Unit Test Framework) - metody w makrze TEST_METHOD i asercje Assert::IsTrue, Assert::AreEqual. Użyj tej biblioteki, którą masz na stanowisku egzaminacyjnym.

Arkusze z testami jednostkowymi wymagają w folderze testy:

• archiwum całego projektu z testami (INF.04-02-25.06-SG: „Utwórz archiwum ZIP zawierające cały projekt”),
• pliki z metodami testującymi - skopiowane poza archiwum, żeby egzaminator mógł je przeczytać bez rozpakowywania,
• zrzuty test1.png, test2.png...

W tych dwóch arkuszach nie ma folderu dokumentacja, więc plik egzamin zapisuje się bezpośrednio w folderze z numerem zdającego.