Testy jednostkowe w Javie - Istota testów jednostkowych, podstawy JUnit
Materiał przedstawia czym są testy jednostkowe, jakie są ich zalety i wady. Stanowi także praktyczny tutorial do frameworka JUnit. W filmie dowiesz się dlaczego warto testować, z czego składa się test jednostkowy oraz jak go przeprowadzić na praktycznym przykładzie. Materiał ten stanowi wstęp do kompletnej serii filmów o testach jednostkowych w oparciu o technologie: JUnit, TestNG oraz Mockito.
Fanpage: / effectivecode
Projekt z odcinka: github.com/javasolutionspl/un...
Пікірлер: 26
super wartościowy materiał, czekam na kolejne
Dzięki! Pomocny materiał.
Bardzo fajny materiał :) Leci sub i łapka :)
Bardzo dobry materiał, dzięki
Dobra prezentacja, dobra robota 😎
Dobry material!
Super kursik
Kurs spadł mi z nieba ;)
czemu nie piszesz najpierw testów, a dopiero potem kodu? (TDD)
Ja pitole nic nie kumam masakra znowu czarna magia
@sebon11
2 жыл бұрын
Jak dla mnie ok
ja pierdole mogłem zostać raperem
Dlaczego wpisujac adnotacje "@Test" nic mi nie wyskakuje? ;/
a jak to testować jeżeli łaczę sie z JDBC?
Dlaczego nie moge utowrzyc obietku CarService
Super a co z metoda private isCorrect pokrywac testami czy nie ?
@JavaSolutions
4 жыл бұрын
Jak najbardziej można, tylko trzeba zmienić modyfikator dostępu na package-private :) Nie jest to jednak wymagane, jeśli przetestujesz wszystkie przypadki tej metody w metodzie ją wykorzystującej ( takie podejście bym rekomendował w tym przypadku). W bardziej złożonych metodach, które wykorzystują po kilka prywatnych metod, te rozbicie testów na pojedyncze metody jest korzystniejsze ze względu na czytelność. Reasumując: - Prosty przypadek (metoda główna z jedną- dwoma prywatnymi wykonującymi jakąś logikę) lepiej testować w głównej wszystkie casy. - Złożony przypadek(powyżej dwóch prywatnych metod wykonujących jakąś logikę) lepiej zmienić je na package private i przetestować osobno :) Oczywiście to dość subiektywne zdanie, ja zawsze w takich przypadkach biorę pod uwagę opcję, która będzie prostsza, czytelniejsza i łatwiejsza w utrzymaniu.
@zdzichuWentyl
4 жыл бұрын
@@JavaSolutions To ze mozna to ja dobrze wiem ale jakieś są praktyki co lepiej zrobić jestem zdania ze zawsze nasz kod powinien dążyć do ideału w kazdym mozliwym aspekcie
@JavaSolutions
4 жыл бұрын
Zgadzam się, kluczowa jest jak najlepsza jakość kodu. Najistotniejsze jest jednak to aby przetestować wszystkie niezbędne przypadki (wartości graniczne, sytuacje wyjątkowe, null casy itp.) Zwróć uwagę że testując osobno metodę isCorrect() dla przypadku wartości -1 oraz analyzeCarByParams(-1, 2, 3) otrzymamy ten sam przypadek testowy, więc mija się to z celem i mamy duplikat, dlatego lepszym jest testowanie głównej metody, w tym przypadku (analyzeCarByParams).
@zdzichuWentyl
4 жыл бұрын
@@JavaSolutions Ciekawa uwaga ale napewnoe wtedy nie mamy pokrycia kodu w 100 %
@JavaSolutions
4 жыл бұрын
@@zdzichuWentyl Kod nigdy nie powinien być w 100% pokryty testami, dla przykładu możliwie prostego: Robiąc UI w Swingu, układając komponenty w layouty, nie będziesz testował czy dany komponent jest ustawiony w odpowiednim miejscu gdyż to nie ma sensu, ponieważ z łatwością tym ułożeniem zarządzasz z poziomu kodu, nie ma tutaj żadnej logiki do przetestowania. W wielu projektach standardem jest 20 - 30% pokrycia kodu testami i takie projekty działają dość niezawodnie.
A może tak ? TREAD_THICKNESS(2, Integer.MAX_VALUE);
mileage!
@mrkilwag
8 ай бұрын
cicho! milasz!