Jak w temacie. Piszemy sobie jakąś prostą klasę, kilka metod. Tworzymy teraz jakis kod w main, który ją wykorzystuje. Czy to jest testowanie ? Bo często widzę w ofertach pracy, wymaganie znajomości, a szczerze nie wiem do końca o co chodzi. Mógłby ktoś jasno to wytłumaczyć, podać ewentualnie jakąś literaturę ?
2
6
To co napisałeś to jest jakiśtam test, ale dość słaby i ograniczony. Zwykle chodzi o umiejętność pisania testów jednostkowych, czyli metod wpiętych do frameworka testowego, które można odpalić jednym kliknięciem i zobaczyć czy wszystko jest ok. Taki framework udostępnia zwykle mechanizmy asercji (czyli pozwala sprawdzić czy wyniki operacji są takie jakich oczekiwaliśmy). Zwykle razem z takim frameworkiem używa się biblioteki do mocków. Co to są mocki? To są obiekty które mają zastępować inne obiekty. Po co? Test jednostkowy zwykle ma za zadanie przetestować mały fragment kodu, np. jedną metodę. Żeby to zrobić musimy zagwarantować że wszystkie inne metody do ktorych się odwoła zwrócą nam odpowiednie wartości. Po to właśnie używamy mocka, którego konfigurujemy tak żeby zwracał nam te wartości które chcemy (dzięki temu możemy łatwo przetestować wszystkie możliwości, wraz z sytuacjami awaryjnymi i błędami).
5
@przybysz Andrzej:
Jeśli szukałbym programistów, którzy sami potrafią zapewnić jakość i poprawność swojego oprogramowania, lub po prostu specjalistów od samego zapewniania jakości kodu (=testerów lub specjalistów SQA, od Software Quality Assurance), to stosowanie opisanych przez Ciebie czynności -- dorzucanie do main() jakiegoś testującego na pałę kodu -- uważałbym za dalece niewystarczające.
W testowaniu automatycznym bardzo ważne jest, by testy posiadały kilka cech. Należy do nich możliwość uruchomienia jednym, prostym poleceniem oraz uzyskanie jednoznacznej, "atomowej" odpowiedzi: czy testy przeszły i wszystko jest OK, czy nie. W przypadku, gdy testy zawiodły, należy podać przyczyny błędów. Ale ważne jest, by można jednym spojrzeniem ocenić, czy wszystko jest OK, czy nie, bez potrzeby głębszej analizy tego, co testy zwróciły na wyjściu. Tj. nie może być tak, że testy wyświetlają ciągi komunikatów w stylu: "Dodaję 2 różnych użytkowników... Próbuję dodać duplikat drugiego użytkownika... Liczba użytkowników w bazie: 2". Nie. Powinny raczej wyświetlić po prostu wielkie, zielone "OK", ew. z pewnymi statystykami, lub czerwone "Wystąpiły błędy!!!", również ze statystykami (ile testów wykonano, ile przeszło) i szczegółowymi komunikatami w stylu "Dodanie duplikatu użytkownika: oczekiwano 2 użytkowników w bazie, ale było 3".
Od tego właśnie masz frameworki testowe, ale jeśli ktoś napisałby własny mini-framework do testów automatycznych i posiadałby on podstawowe cechy tych normalnych frameworków, to dla mnie byłoby to w miarę wystarczające. Istniejących, dużych/fajnych frameworków można się przecież nauczyć znacznie łatwiej niż samej dyscypliny testowania!
A właśnie: testy automatyczne dzielą się na kilka rodzajów.
@Shalom pisał o testach jednostkowych, testujących małe fragmenty kodu -- małe metody. Oprócz tego, są jeszcze testy integracyjne, które pisze się w zasadzie tak samo, ale które koncentrują się na współpracy kilku modułów.
No i są jeszcze testy end-to-end, sprawdzające bardzo wysokopoziomowe działanie aplikacji, od samego początku do samego końca, wszystkie warstwy. Nawet tak, że symulujemy kliknięcie użytkownika w jakiś przycisk i patrzymy, co aplikacja wyświetli ostatecznie na ekranie.
Istnieją specjalne metodologie koncentrujące się na testowaniu. Np. TDD, Test-Driven Development. W tej metodologii nie zaczynasz od napisania klasy z kilkoma metodami. Zaczynasz od stworzenia testów. Wyobrażasz sobie, jak Twoja klasa ma wyglądać, metoda po metodzie. Jak dana metoda powinna się nazywać? Co ma zwracać? Jakie ma mieć skutki uboczne? Piszesz do niej testy. Potem tworzysz zalążek tej metody -- bez właściwego kodu -- tak, by całość wraz z testami się kompilowała. Odpalasz testy i patrzysz, czy zawiodły (powinny, bo testowana metoda jeszcze nic nie robi!). Następnie uzupełniasz tę metodę kodem właściwym w ten sposób, by testy zapaliły się na zielono. I przechodzisz do następnej metody.
Co do źródeł, to pogooglaj sobie "unit testing", "automatic testing", "tdd". W czym piszesz, w Javie? To obadaj "junit", znany framework do testów jednostkowych.
Książki fajne istnieją, choć na polskim rynku nieco gorzej. Była cienka książeczka o JUnicie ( http://helion.pl/ksiazki/junit-pragmatyczne-testy-jednostkowe-w-javie-andy-hunt-dave-thomas,junit.htm ) prezentująca fundamenty testów jednostkowych, ale widzę, że mogą być teraz problemy z dostępnością. Do tego można zainwestować w "Czysty kod" Roberta C. Martina, w którym Wujek Bob ogólnie uczy pisania kodu wysokiej jakości, a testy czy refaktoryzacja są po prostu integralną częścią tego procesu.
A jeśli szperasz w oferach pracy dla "specjalistów SQA", tj. testerów, to tu robota przeważnie jest trochę inna. Zależnie od firmy i stanowiska, pisze się testy end-to-end, ale często najbardziej czasochłonną robotą są klasyczne testy ręczne (wsparte pewnymi automatami). Tj. ci testerzy są po prostu przeszkoleni w tym, jak używać aplikacji, by wykryć jak najwięcej błędów (np. stosują różne przypadki brzegowe, podają dane w złym formacie etc.). W przypadku programistów, takie "ręczne" testowanie nie powinno stanowić dużej części pracy.
0
Czyli w clean code będzie o testowaniu ?
0
Bardziej nazewnictwo, refactoring, podział odpowiedzialności itp. Ogólnie polecam tę książkę. Testowaniu jednostkowemu poświęcony jest jeden rozdział.
0
Aha. A testy ręczne można zastąpić jakimiś skryptami chyba ?
0
Co rozumiesz przez "testy ręczne"? Testy GUI można automatyzować, są do tego narzędzia takie jak Selenium.
0
bswierczynski_wylog. napisał(a):
Zależnie od firmy i stanowiska, pisze się testy end-to-end, ale często najbardziej czasochłonną robotą są klasyczne testy ręczne (wsparte pewnymi automatami). Tj. ci testerzy są po prostu przeszkoleni w tym, jak używać aplikacji, by wykryć jak najwięcej błędów (np. stosują różne przypadki brzegowe, podają dane w złym formacie etc.). W przypadku programistów, takie "ręczne" testowanie nie powinno stanowić dużej części pracy.
Takie cos
0
Nie w tym rzecz, różne rodzaje testów przydają się na różnych etapach, różnym ludziom, sprawdzają różne rzeczy.
Inne osoby piszą np. testy jednostkowe, inne osoby testują oprogramowanie przeklikując się przez nie. Są różne rodzaje testów, na różnych poziomach abstrakcji. Te testy się uzupełniają, a nie zastępują jeden drugim.
0
No to przecież masz napisane jak byk: "wsparte automatami". Jednym z takich automatów jest właśnie selenium. Ale nie wszystko da się zrobić automatycznie. Zauważ że testy ręczne polegają na tym że ktoś klika sobie w GUI różne opcje i sprawdza co się dzieje. Czego nie da się tak prosto zamodelować automatycznie? Na przykład zachowania niecierpliwego usera który klika po kilka razy pod rząd albo przytrzymuje klawiszem guzik, przy okazji jeszcze stuka w klawiaturę etc.
W efekcie sporo firm zatrudnia testerów manualnych.
0
W temacie testów - czytam od paru miesięcy fajnego bloga, gdzie dziewczyna dzieli sie fajnymi spostrzeżeniami - http://blog.testility.pl/ - pozdro!
0
Alternatywą JUnit jest TestNG.
Z przydatnych rzeczy jest jeszcze http://www.sonarsource.org/
0
Jeszcze inną alternatywą jest: http://jbehave.org/