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

[@robertstan6108]

super wartościowy materiał, czekam na kolejne

[@jakubkiljanski4950]

Dzięki! Pomocny materiał.

[@wacekwacek5971]

Dobry material!

[@programistaanonimowy8657]

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

[@Micha-ns3db]

Dobra prezentacja, dobra robota 😎

[@przemysawtyczyno1086]

Bardzo dobry materiał, dzięki

[@mrkilwag]

Super kursik

[@kubawroblewski8400]

Ja pitole nic nie kumam masakra znowu czarna magia

[@sebon11]

Jak dla mnie ok

[@kamilwitkowski2521]

Kurs spadł mi z nieba ;)

[@hubert3728]

Dlaczego nie moge utowrzyc obietku CarService

[@joachiml4238]

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

[@hubert3728]

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

[@tomaszszybicki6392]

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

[@vinci_irl]

ja pierdole mogłem zostać raperem

[@zdzichuWentyl]

Super a co z metoda private isCorrect pokrywac testami czy nie ?

[@JavaSolutions]

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]

​@@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]

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]

@@JavaSolutions Ciekawa uwaga ale napewnoe wtedy nie mamy pokrycia kodu w 100 %

[@JavaSolutions]

@@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.

[@charlesLeeRay]

A może tak ? TREAD_THICKNESS(2, Integer.MAX_VALUE);

[@przemyslawgasecki4817]

mileage!

[@mrkilwag]

cicho! milasz!