Czy potrzebujemy danych testowych, czy możemy polegać na testach jednostkowych i testach ręcznych?

Aktualnie pracujemy nad średnim / dużym projektem PHP / MySQL. Przeprowadzamy testy jednostkowe z PHPUnit i QUnit i mamy dwóch pełnoetatowych testerów, którzy ręcznie testują aplikację. Nasze dane testowe (próbne) są obecnie tworzone za pomocą skryptów SQL.

Mamy problem z utrzymywaniem skryptów dla danych testowych. Logika biznesowa jest dość złożona, a jedna „prosta” zmiana danych testowych często powoduje kilka błędów w aplikacji (które nie są prawdziwymi błędami, tylko produktem nieprawidłowych danych). Stało się to dużym obciążeniem dla całego zespołu, ponieważ stale tworzymy i zmieniamy tabele.

Naprawdę nie widzę sensu utrzymywania danych testowych w skryptach, ponieważ wszystko można ręcznie dodać w aplikacji w około 5 minut za pomocą interfejsu użytkownika. Nasz szef nie zgadza się z tym i mówi, że posiadanie projektu, którego nie możemy wdrożyć z danymi testowymi, jest złą praktyką.

Czy powinniśmy zrezygnować z obsługi skryptów z danymi testowymi i pozwolić testerom przetestować aplikację bez danych? Jaka jest najlepsza praktyka?

— Christian P.
źródło

Odpowiedzi:

Mieszacie dwie różne koncepcje. Jednym z nich jest weryfikacja oparta na testach jednostkowych i recenzjach. Mogą to zrobić sami programiści, bez danych testowych, a ich celem jest sprawdzenie, czy zestaw wymagań został spełniony.

Drugi to sprawdzanie poprawności i odbywa się to przez QA (testerów). Do tego kroku potrzebne są dane testowe, ponieważ tester nie musi mieć żadnej wiedzy na temat programowania w aplikacji, a jedynie zamierzone przypadki użycia. Jego celem jest sprawdzenie, czy aplikacja zachowuje się zgodnie z przeznaczeniem w środowisku produkcyjnym.

Oba procesy są ważne i konieczne, aby dostarczyć klientowi produkt wysokiej jakości. Nie możesz polegać wyłącznie na testach jednostkowych. To, co musisz ustalić, to niezawodny sposób obsługi danych testowych, aby zapewnić ich poprawność.

EDYCJA: OK, rozumiem o co prosisz. Odpowiedź brzmi tak, ponieważ zadaniem testera nie jest generowanie danych testowych, a jedynie testowanie aplikacji. Musisz zbudować skrypty w sposób umożliwiający łatwiejszą konserwację i zapewniający wstawienie prawidłowych danych. Bez danych testowych tester nie będzie miał nic do przetestowania. Powiedziawszy to jednak, jeśli masz dostęp do środowiska testowego , nie rozumiem, dlaczego nie możesz wstawić danych testowych ręcznie, a nie za pomocą skryptów.

— AJC
źródło

Być może podałem błędne pytanie, wspominając o testowaniu jednostkowym i danych testowych. Rozumiem, że walidacja to nie to samo, co testowanie jednostkowe. Mój problem polega na tym, że dane testowe, które tworzymy za pomocą skryptów, można utworzyć za pomocą interfejsu użytkownika w 5 minut. Aby wstawić te dane do aplikacji, nie musisz znać programowania, wystarczy postępować zgodnie z przypadkami testowymi.

— Christian P

@ christian.p sprawdź moją aktualizację dotyczącą wyjaśnienia pytania.

— AJC

Czy Twoim rozwiązaniem jest porzucenie skryptów i dodanie ręcznych danych testowych za pomocą interfejsu użytkownika? A co z odpowiedzią udzieloną przez P.Briana Maceya i jego odpowiedziami na połączenie danych z interfejsem użytkownika?

— Christian P

@ christian.p Cóż, zgadzam się, że powinieneś używać skryptów. ALE nie ma formalności ani reguły, która mówi, że musisz. Głównym powodem używania skryptów do generowania fałszywych danych jest szybkość (automatyzacja) i dostęp (do środowiska testowego). Jeśli masz dostęp i jest to szybsze i łatwiejsze do zrobienia ręcznie, nie ma powodu, aby tego nie robić. (ALE przechowuj dane, które testowałeś).

— AJC

każdy tester ma własne środowisko testowe, a testerzy całkowicie usuwają bazę danych kilka razy dziennie, więc ręczne dodawanie danych testowych jest niepraktyczne, ale możemy uprzejmie poprosić ich o dodanie niektórych danych do testowania.

— Christian P

Tak, najlepszą praktyką jest posiadanie testów jednostkowych i makiet danych. Kierownik projektu ma rację. Ponieważ wykonanie „prostej” zmiany danych testowych często powoduje błędy, to jest sedno problemu.

Kod wymaga ulepszenia. Nie robienie tego (mówiąc „hej, nie potrzebujemy testów”) nie jest naprawą, to po prostu dodanie długu technicznego . Podziel kod na mniejsze, bardziej testowalne jednostki, ponieważ niemożność zidentyfikowania jednostek bez uszkodzenia jest problemem.

Zacznij robić refaktor. Ulepszenia powinny być małe, aby można było nimi zarządzać. Szukaj anty-wzorów, takich jak klasy / metody Boga, nie przestrzegaj SUCHEJ, pojedynczej odpowiedzialności itp.

Na koniec spójrz na TDD, aby sprawdzić, czy to działa dla zespołu. TDD działa dobrze, zapewniając, że cały twój kod jest możliwy do przetestowania (ponieważ najpierw piszesz testy), a także upewniasz się, że jesteś szczupły , pisząc tylko tyle kodu, aby przejść testy (zminimalizować nad inżynierią).

Ogólnie rzecz biorąc, jeśli seria złożonych procesów logiki biznesowej generuje zestaw danych, uważam to za raport. Podsumuj raport. Uruchom raport i użyj wynikowego obiektu jako danych wejściowych do następnego testu.

— P.Brian.Mackey
źródło

Muszę trochę wyjaśnić: „Prosta zmiana danych testowych powoduje błędy” - problemem nie jest tutaj aplikacja - aplikacja działa poprawnie, gdy dane są prawidłowe (i nie można ręcznie dodać nieprawidłowych danych) . Problem polega na tym, że nieprawidłowe dane testowe mogą powodować błędy podczas próby pracy na tych danych. Więc musimy również przetestować dane testowe?

— Christian P

Nie daj się potknąć fałszywemu czerwonemu śledziu. Fakt, że dane testowe wprowadzają błąd, to zupełnie inna sprawa. Usunięcie testów nie jest naprawą, „rządzenie rządem” to także coś zupełnie innego. Problemem jest kod. Nie można tego przetestować, ponieważ mówisz nam, że nie możesz pisać testów, które nie psują rzeczy. Dlatego musisz poprawić kod.

— P.Brian.Mackey,

Może źle zrozumiałeś moje pytanie. Mamy działające testy jednostkowe i każda nowa pisana funkcjonalność ma testy jednostkowe. Nie sugeruję, że usuwamy testy, które nie przechodzą lub że w ogóle nie piszemy testów. Po prostu sugeruję, abyśmy nie używali skryptów do tworzenia fałszywych danych w bazie danych, ponieważ testerzy ręczni robią to samo.

— Christian P

„Naprawdę nie widzę sensu utrzymywania danych testowych w skryptach” <- Mówię o rezygnacji z obsługi testów. Nie usuwanie starych testów. To zły pomysł. Zmniejszasz odtwarzalność i łączysz się z interfejsem użytkownika, który jest częścią tego, co próbujesz przetestować i być w stanie dostosować się do zmian. Odłącz się od interfejsu użytkownika. Zachowaj automatyzację danych.

— P.Brian.Mackey,

Ale jak rozwiązać problem nieprawidłowych fałszywych danych? Jeśli nadal będziemy tworzyć fałszywe dane dla bazy danych, jak sprawdzimy, czy fałszywe dane są prawidłowe, czy nie? Jeśli reguła biznesowa wymaga tej wartości X = 2, a baza danych przyjmuje X = 100 - jak sprawdzić integralność danych testowych, gdy reguła biznesowa jest złożona?

— Christian P

Jest to bardzo powszechny i bardzo trudny problem. Zautomatyzowane testy, które działają przeciwko databse (nawet bazy danych w pamięci, takich jak HSQLDB ) są zwykle powolny, nie deterministyczny, a ponieważ tylko awaria badanie wskazuje, że istnieje problem gdzieś w kodzie lub w Panstwa danych, są one mało pouczające.

Z mojego doświadczenia wynika, że najlepszą strategią jest skupienie się na testach jednostkowych dla logiki biznesowej. Postaraj się pokryć jak najwięcej swojego podstawowego kodu domeny. Jeśli dobrze zrozumiesz tę część, co samo w sobie jest sporym wyzwaniem, osiągniesz najlepszy stosunek kosztów do korzyści dla automatycznych testów. Jeśli chodzi o warstwę trwałości, zwykle poświęcam znacznie mniej wysiłku na testy automatyczne i pozostawiam to dedykowanym testerom ręcznym.

Ale jeśli naprawdę chcesz (lub potrzebujesz) zautomatyzować testy trwałości, polecam lekturę Growing Object-Oriented Software, Guided by Tests . Ta książka zawiera cały rozdział poświęcony testom trwałości.

— Otavio Macedo
źródło