Testy jednostkowe w Javie - Istota testów jednostkowych, podstawy JUnit

Рет қаралды 13,587

Күн бұрын

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

@robertstan6108 4 жыл бұрын

super wartościowy materiał, czekam na kolejne

@jakubkiljanski4950 Жыл бұрын

Dzięki! Pomocny materiał.

@mrkilwag 8 ай бұрын

Super kursik

@programistaanonimowy8657 4 жыл бұрын

Bardzo fajny materiał :) Leci sub i łapka :)

@wacekwacek5971 9 ай бұрын

Dobry material!

@Micha-ns3db 3 жыл бұрын

Dobra prezentacja, dobra robota 😎

@przemysawtyczyno1086 3 жыл бұрын

Bardzo dobry materiał, dzięki

@kamilwitkowski2521 4 жыл бұрын

Kurs spadł mi z nieba ;)

@kubawroblewski8400 3 жыл бұрын

Ja pitole nic nie kumam masakra znowu czarna magia

@sebon11 2 жыл бұрын

Jak dla mnie ok

@vinci_irl 2 жыл бұрын

ja pierdole mogłem zostać raperem

@tomaszszybicki6392 3 жыл бұрын

czemu nie piszesz najpierw testów, a dopiero potem kodu? (TDD)

@joachiml4238 Жыл бұрын

a jak to testować jeżeli łaczę sie z JDBC?

@hubert3728 Жыл бұрын

Dlaczego wpisujac adnotacje "@Test" nic mi nie wyskakuje? ;/

@hubert3728 Жыл бұрын

Dlaczego nie moge utowrzyc obietku CarService

@zdzichuWentyl 4 жыл бұрын

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.