Czy wszystkie testy jednostkowe powinny zakończyć się powodzeniem?

Question

Załóżmy, że tworzysz aplikację, która próbuje transliterować elementy z alfabetu A do alfabetu B tak dokładnie, jak to możliwe.

Ponieważ język B jest bardzo złożony, nie zawsze się to udaje. Ale otrzymujesz przybliżoną transliterację.

Jak zbudowałbyś testy jednostkowe w tym przypadku, biorąc pod uwagę, że spodziewasz się 20-30% porażki?

Answer 1

Zawsze musi być celem, aby test jednostkowy zakończył się powodzeniem. Sposób, w jaki go używasz, nie pozwala odróżnić poważnych błędów w oprogramowaniu od błędów w tłumaczeniach, których się spodziewasz.

Proponuję oddzielić obie:

1. testy Zastosowanie jednostkowych tylko upewnić się, że oprogramowanie działa w ten sposób można się spodziewać (nawet jeśli zawiera jakieś błędy w tłumaczeniach)
2. produkować test zbiór danych zawierający tłumaczenia wygenerowane przez twoje oprogramowanie. Możesz sprawdzić ten zestaw danych testowych ręcznie lub używając pakietu oprogramowania statystycznego, takiego jak R, aby uzyskać pojęcie o jakości twoich tłumaczeń.

Answer 2

Test jednostkowy, który powinien zakończyć się niepowodzeniem, nie jest testem jednostkowym. Musisz zmienić definicję sukcesu, używając funkcji oceny, która działa jak filtr i decyduje, czy jest "wystarczająco blisko" i określa pass/fail. Gdy Twój tłumacz poprawi się, możesz podnieść poprzeczkę w filtrze.

Answer 3

Test jednostkowy powinien być deterministyczny. Awaria testu powinna wskazywać awarię oprogramowania, a nie coś, co "działa zgodnie z przeznaczeniem". W twoim przypadku przygotuj dane w taki sposób, abyś był pewien wyników i przetestuj je, czy konwersja się powiedzie lub się nie powiedzie (testowanie na awarię jest zawsze opcjonalne, zważywszy, że oczekujesz porażki - ważne jest to, że zawsze masz kontrolę kiedy twój test się nie powiedzie).

Answer 4

Techniką, której nauczyłem się w tej sytuacji, jest przetestowanie tylko tych części kodu, które są funkcjonalne (lub deterministyczne). Oczywiście trudna część, jeśli oddzielić deterministyczny od niedeterministycznych części. Stenograficznym sposobem na powiedzenie tego jest "zredukowanie [lub refaktor] do funkcjonalności", co oznacza oddzielenie części kodu, które są deterministyczne, a następnie przetestowanie tych części.

Dla nieco scenariuszy opartych na kontekście, przeczytaj ten blog post o zastosowaniu tej techniki, kiedy zaczyna testy na całym starszych kod (i korzystania z open source testów jednostkowych bibliotekę o nazwie ApprovalTests).

Jeszcze inną techniką, która może być interesująca, jest test oparty na teorii. Aby uzyskać więcej informacji na ten temat, sprawdź ten post blog.

Answer 5

Jedynym powodem, dla którego test jednostkowy może się nie powieść, jest uwzględnienie czasu (głównie w przypadku testowanej elektroniki). Jednak nawet w tych przypadkach celem powinno być usunięcie problemu z synchronizacją z testu urządzenia, np. przez wydłużenie/wyłączenie limitu czasu lub innego problemu, jeśli to możliwe. Gdy nie jest to możliwe, powinno być dobrze udokumentowane.

Innym sposobem na usunięcie problemów z określaniem czasu i określenie deterministycznych testów jest napisanie kodu pośredniczącego dla wszystkich zewnętrznych interfejsów, z pewną metodą wtrysku, tj. Możliwość ustawienia wartości, które zwrócą metody zewnętrznego interfejsu. Ustawiając w ten sposób test jednostkowy, można dosłownie przetestować wszystko, również pod kątem każdego błędu.

(historia: pracowałem w firmie, w której kilka testów jednostkowych okazjonalnie nie udawało się, tylko kilka osób mogło przeanalizować, czy były to poważne błędy, czy problem z regulacją czasu, zaoszczędzi to dużo czasu na wykonanie dobrych testów jednostkowych w pierwsze miejsce).