W jaki sposób testowanie jednostek działa, gdy program nie nadaje się do stylu funkcjonalnego?

Question

Mam na myśli przypadek, w którym program tak naprawdę niczego nie oblicza, to po prostu dużo. Testowanie jednostek ma dla mnie sens, gdy piszesz funkcje, które kalkulują coś i musisz sprawdzić wynik, ale co, jeśli niczego nie obliczasz? Na przykład program, który utrzymuję w pracy, polega na tym, aby użytkownik wypełnił formularz, a następnie otworzył zewnętrzny program i zautomatyzował zewnętrzny program, aby zrobił coś na podstawie danych wprowadzonych przez użytkownika. Proces jest dość zaangażowany. Jest tam 3000 linii kodu (rozłożonych na wiele funkcji *), ale nie mogę wymyślić ani jednej rzeczy, która ma sens dla testu jednostkowego.

To tylko przykład. Czy powinieneś nawet spróbować testować programy "proceduralne"?

* EDIT

Answer 1

Na podstawie opisu są to miejsca, będę szukać do testów jednostkowych:

• Czy praca walidacja forma pracy wejściowego użytkownika poprawnie
• Biorąc pod uwagę ważność wejście od formy jest zewnętrzny program nazywa poprawnie
• Kanał na wejściu użytkownika do programu zewnętrznego i sprawdzić, czy masz prawo wyjście

Od dźwięków opisie prawdziwym problemem jest to, że Kod, z którym pracujesz, nie jest modułowy. Jedną z korzyści, które napotykam podczas testowania jednostkowego, jest to, że kod, który jest trudny do sprawdzenia, nie jest wystarczająco modułowy lub ma niewygodny interfejs. Spróbuj złamać kod na mniejsze kawałki, a znajdziesz miejsca, w których warto pisać testy jednostkowe.

Answer 2

Należy przynajmniej byłaby out materiał, który wygląda jak może to być problem i że testy jednostkowe. Ale z reguły funkcja nie powinna być tak długa. Może się okazać, że coś jest badanej jednostki godne po uruchomieniu refactoring

Good object mentor article on TDD

Answer 3

nie jestem ekspertem w tej sprawie, ale były mylone przez jakiś czas z tego samego powodu. W jakiś sposób aplikacje, które robię, nie pasują do przykładów podanych dla testów UNIT (bardzo asynchronicznych i losowych w zależności od intensywnej interakcji użytkownika) Ostatnio zdałem sobie sprawę (i proszę dać mi znać, jeśli się mylę), że nie robi tego ". ma sens, aby przeprowadzić globalny test, ale raczej niezliczoną ilość drobnych testów dla każdego komponentu. Najłatwiej jest zbudować test w tym samym czasie lub nawet przed utworzeniem rzeczywistych procedur.

Answer 4

Czy masz 3000 linii kodu w pojedynczej procedurze/metodzie? Jeśli tak, to prawdopodobnie musisz zmienić swój kod na mniejsze, bardziej zrozumiałe elementy, aby można było je utrzymać. Kiedy to zrobisz, będziesz miał te części, które możesz i powinieneś testować. Jeśli nie, to masz już te elementy - poszczególne procedury/metody, które są wywoływane przez twój główny program.

Mimo to, nawet bez testów jednostkowych, nadal powinieneś napisać testy kodu, aby upewnić się, że podajesz prawidłowe dane wejściowe do zewnętrznego programu i testujesz prawidłowe obsłużenie wyjść programu w warunkach normalnych i wyjątkowych . Techniki używane w testach jednostkowych - np. Szydercze - mogą być używane w tych testach integracyjnych, aby upewnić się, że twój program działa poprawnie, nie angażując zewnętrznego źródła.

Answer 5

Nie musisz koniecznie wdrażać automatycznych testów testujących poszczególne metody lub komponenty. Można zaimplementować zautomatyzowany test jednostkowy, który symuluje interakcję użytkownika z aplikacją i przetestować, czy aplikacja reaguje we właściwy sposób.

Zakładam, że obecnie ręcznie testujesz aplikację, jeśli tak, to zastanów się, jak możesz ją zautomatyzować i zacząć pracę. Z biegiem czasu powinieneś być w stanie przerwać testy na coraz mniejsze fragmenty testujące mniejsze sekcje kodu. Każde automatyczne testowanie jest zwykle o wiele lepsze niż nic.

Answer 6

Większość programów (niezależnie od paradygmatu języka) może być podzielona na jednostki atomowe, które pobierają dane wejściowe i dostarczają dane wyjściowe. Jak wspomnieli inni respondenci, popatrzcie na refaktoryzację programu i podzielcie go na mniejsze części. Podczas testowania skup się mniej na kompleksowej funkcjonalności, a bardziej na poszczególnych etapach przetwarzania danych.

Ponadto, jednostka niekoniecznie musi być funkcją indywidualną (choć często tak jest). Jednostka to segment funkcjonalności, który można testować za pomocą wejść i wyjść pomiarowych.Widziałem to podczas używania JUnit do testowania Java API. Indywidualne metody niekoniecznie dostarczają ziarnistości potrzebnej do testowania, chociaż seria wywołań metod będzie. Dlatego funkcja, którą uważam za "jednostkę", jest trochę większa niż pojedyncza metoda.

Answer 7

Kilka osób odpowiedziało już wcześniej, jest kilka sposobów na sprawdzenie tego, co nakreśliłeś. Najpierw dane wejściowe formularza można przetestować na kilka sposobów. Co się stanie, jeśli wprowadzone zostaną nieprawidłowe dane, prawidłowe dane itp. Następnie można sprawdzić każdą z funkcji, aby sprawdzić, czy funkcje dostarczane z różnymi formami poprawnych i niepoprawnych danych reagują we właściwy sposób. Następnie możesz sfałszować wywoływaną aplikację, aby upewnić się, że aplikacja prawidłowo wysyła i przetwarza dane do zewnętrznych programów. Nie rób tego, aby upewnić się, że Twój program radzi sobie z nieoczekiwanymi danymi z zewnętrznego programu.

Zazwyczaj sposób, w jaki próbuję napisać testy dla programu, który został mi przydzielony do utrzymania, polega na sprawdzeniu, co robię ręcznie w celu przetestowania programu. Następnie spróbuj dowiedzieć się, jak zautomatyzować jak najwięcej z nich. Nie ograniczaj swoich narzędzi testowych tylko do języka programowania, w którym wpisujesz kod.

Answer 8

Ciekawym "punktem końcowym" dla Twojej aplikacji jest "użytkownik wypełnia formularz". Jeśli chcesz przetestować, powinieneś zreorganizować swój kod, aby skonstruować wyraźną reprezentację tego formularza jako struktury danych. Następnie możesz zacząć zbierać formularze i testować, czy system odpowiada odpowiednio na każdy formularz.

Możliwe, że działania podejmowane przez system nie są możliwe do zaobserwowania, dopóki coś nie uderzy w system plików. Oto kilka pomysłów:

• Konfigurowanie coś takiego repozytorium git do początkowego stanu systemu plików, należy uruchomić formularz i spojrzeć na wyjściu git diff. Prawdopodobnie będzie to bardziej przypominało testowanie regresji niż testowanie jednostkowe.

• Utwórz nowy moduł, którego jedynym celem jest umożliwienie obserwowania działań programu. Może to być tak proste, jak zapisywanie odpowiedniego tekstu w pliku dziennika lub tak skomplikowane, jak chcesz. Jeśli to konieczne, możesz użyć warunkowej kompilacji lub łączenia, aby upewnić się, że moduł robi coś tylko wtedy, gdy system jest testowany. Jest to bliższe tradycyjnym testom jednostkowym, ponieważ można teraz pisać testy, które mówią: po otrzymaniu formularza A, system powinien wykonać sekwencję czynności B. Oczywiście musisz zdecydować, jakie działania należy podjąć, aby stworzyć rozsądny test.

Podejrzewam znajdziesz się migrację w kierunku czegoś, co wygląda bardziej jak testowanie regresji niż testów jednostkowych per se. To niekoniecznie jest złe. Nie zapomnij o zasięgu kodu!

(Ostatnia uwaga w nawiasie: w dawnych, złych czasach interaktywnych aplikacji konsolowych, Don Libes stworzył narzędzie o nazwie Expect, które było niezwykle pomocne przy pisaniu programu, który działał jak użytkownik. Potrzebuję czegoś podobnego do interakcji ze stronami internetowymi. Myślę, że zadam pytanie na ten temat :-)

Answer 9

Myślę, że fala testowania paranoi rozszerza się :) Dobrze jest badać rzeczy, aby sprawdzić, czy testy miałyby sens, czasami odpowiedź brzmi "nie".

Jedyne, co chciałbym przetestować, to upewnienie się, że fałszywe dane wejściowe są poprawnie obsługiwane. Naprawdę nie widzę, gdzie jeszcze mógłby pomóc automatyczny test. Myślę, że chciałbyś, aby test był nieinwazyjny (tzn. Żaden zapis nie został zapisany podczas testowania), więc może wykluczyć inne możliwości.

Answer 10

Jeśli nie możesz przetestować czegoś, skąd wiesz, że to działa? Kluczem do projektowania oprogramowania jest to, że kod powinien być testowalny. Może to utrudnić faktyczne pisanie oprogramowania, ale później opłaca się ułatwić konserwację.