Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...
Bernard Potocki:
Zazwyczaj staram się nie udzielać, ale tu pobiliście wszystkie rekordy...
Też mi się nie chciało użerać z ludźmi, którzy myślą, że wiedzą dużo o testowaniu i developerce, ale cóż. Poziom Przekręceń pojęć sięga zenitu.
Po pierwsze - nie istnieje coś takiego jak "Test Driven Design" - jeśli myślisz o tym linku to człowiek który to pisał pomylił z Test Driven Development(chociaż jeśli to jest w tytule to zaliczył fail roku - albo i 6 w tym wypadku...) Co zresztą jasno wynika z przedstawionej przez niego metodologii. </thread> więc dla tego tematu.
True, nie jest to powszechnie stosowane pojęcie, raczej sztuczne. Chodzi o to, żeby na kazdym etapie projektu myśleć jak umożliwić jego łatwe przetestowanie. Jednakże w tym wątku TDD to Test Driven Development.
Dalej - pisanie testów unitowych. Tutaj albo ktoś przytrollował, albo naprawdę nie wie jak wyglądają testy. Bo niby jak napisać testy do czegoś czego nie ma??
Nie prawda. Na tym polega Test Driven Development. Piszesz test, który ma udowodnić, że nowa funkcjonalność działa. Test daje fail, dopisujesz kod i test robi się zielony.
Można napisac testy integracyjne(np. Cucumber) do opisanej funkcjonalności. Ale testy unitowe(modeli), funkcjonalne(kontrolerów) i widoków są pisane na podstawie kodu - bo to kod a nie funkcje mają te testy sprawdzać. Więc proponuję poczytać, pokontemplować i dopiero kontynuować dyskusję na ten podtemat.
Również proponuje Ci poczytać ale o testowaniu. Podział testów nie opiera się na modelu MVC.
Testy Modułowe (Unit Testy) - testy pojedynczego modułu dostarczającego określoną funkcjonalność
Testy Integracyjne - testy dwóch lub więcej modułów/systemów pracujących zależnie
Testy Systemowe - testy całego systemu, testy całego workflow od wejścia do wyjścia
Testy Akceptacyjne - na ogól podzbiór testów systemowych wykonywany na środowisku takim samym lub zbliżonym do produkcyjnego, czesto wykonywane przez inną firmę lub klienta
I ostatnia rzecz - tester. Daj biednemu człowiekowi do napisania trochę kodu to się załamie. Tester jest od testowania a nie od klepania kodu. Więc nie - nie pisze unit testów, nie pisze testów funkcjonalnych ani nawet integracyjnych. On ma przeczesać aplikację jako użytkownik - czyli z palca jak Pan Bóg przykazał. Jeśli macie wysokiej jakości testera to dodatkowo może znać Selenium czy coś pokrewnego - wtedy to z pewnością poprawi jakość jego testów(bo może zapuścić je żeby całą aplikację objechały a w międzyczasie dać odpocząć skołatanym nerwom np. na 4chanie) ale potem i tak musi się sam przeklikać żeby sprawdzić czy się layout pod IE nie rozwala, czy JavaScript działa i flash wygląda jak przystało, a nie jak Silverlight...
Wrong! Tester to osoba, która testuje, więc jeżeli kolega z zespołu pisze testy do twojego kodu to w tym momencie jest on testerem. Testerzy, którzy zajmują się White Box Testing też muszą znać się na kodzie. Żadko, ale jednak zdarza się że są w zespole osoby, które zajmują się sprawdzaniem jakości Unit Testów, albo zajmują się wyłacznie dopisywaniem Unit Testów. Są też testerzy, którzy tworzą narzędzia do testów automatycznych albo symulatory. Z Twojej wypowiedzi wynika, że widziałeś tylko pracę testera od Testów Akceptacyjnych albo monkey testing.
Podsumowując - Panowie mniej rage'a a więcej tłumaczenia, a koledze zakładającemu topic proponuję skupiać się na sednie sprawy a nie na ozdobnikach językowych, tudzież porównywaniu długości z pozostałymi użytkownikami(ale to akurat dotyczy chyba wszystkich w tym temacie...)
Fakt, poziom tematu jest niski, ale nie obarczałbym winą za to założyciela.
EDIT: po zwróceniu mi uwagi przez jednego współpracownika muszę przyznać że unit testy do nienapisanego kodu można napisać - w teorii to również zakłada TDD. Ale IMHO jest to połowiczna prawda bo i tak potem pisząc modele dodajemy mniej lub bardziej nieplanowane metody do których będzie trzeba dodać testy. Więc pisanie unit testów przed kodowaniem jest możliwe, ale tylko w ograniczonym stopniu.Bernard Potocki edytował(a) ten post dnia 09.07.09 o godzinie 08:58
Nie bądź uparty :) Byłem na szkoleniu z TDD i widziałem jak ładnie za pomocą Eclipse można tworzyć funkcjonalny kod przy okazji pisania JUnitów.
пропозиції роботи
