@F3NRIR: porównać np. sumę kontrolną.

@F3NRIR: nie, tylko warto nabrać intuicji "czy jak test nie przejdzie to ja/ktoś będzie w stanie w miarę szybko ogarnąć co nie działa?". Takie zbiórcze asercje jak np. porówanie outputów z jakiegoś ls są o tyle dobre, że pokazują cały wynik a nie składowe, przez co łatwiej analizować takie testy

@szalony_kefir w mockito jest coś takiego jak verify

@mk321: jak podnosisz context springowy to masz testy integracyjne. Oddzielne testy na kazda klase i testujesz wszystko co w danym pakiecie jest wystawione, a nie tylko publiczne metody. Junit4 skoro mowimy o runnerach, wwiec imo mockitorunner, albo dla jakichs utilsow to parametryzowany runner. Controllery sie testuje z mockmvc I controlleradvice wiec powinno tez walidacje i odpowiedzi na bledy pokryc.

@mk321: testuj logikę a nie czy springowe adnotacje działają, najlepiej też jak nic nie mockujesz

Jeśli testujesz metodę kontrolera który wola serwis który jedyne co robi to wola repo żeby zapisać encje - robisz to źle. W ten sposób przetestowales czy spring działa. Pracownicy pivotala pewnie się ucieszą z dodatkowego testu ( ͡° ͜ʖ ͡°)

Kluczem nie jest 100% coverage-u tylko mądre przetestowanie funkcjonalności, logiki biznesowej

@kam3o: @szczesliwa_patelnia:
https://www.pepper.pl/promocje/ksiazki-papierowe-na-apress-za-darmo-bad-127674
testoviron mial racje ( ͡° ͜ʖ ͡°)

@damianbeat: możesz użyc api slacka do wyslania wiadomosci bezposrednio z testu

@damianbeat: powiadomienia to raczej tak jak mówi @nesti32 , w jenkinsie. Masz nawet dedykowane pluginy do junita (https://wiki.jenkins.io/display/JENKINS/JUnit+Plugin - ostatnio słabo działa wiki, ale działa :P cierpliwośći). Poza tym trochę słabe używać jenkinsa do monitoringu co minutę. Nie możesz triggerować tego z poziomu systemu monitoringu? Wrzucić to do jakiegoś skryptu i zapnij jako external script w zabbiksie, etc.

Dodatkowo - jaka baza? Zamiast monitorować opóźnienia aktywnie próbkująć sztucznymPokaż całość

@damianbeat: ah, no i nie musisz mieć koniecznie junita, jak przeniesiesz logikę tego zapytania na bazę i wrzucisz w jakąś procedurkę składowaną, to możesz to sobie sprowadzić do postaci zerojedynkowej, albo zwracać tylko liczbę (czas opóźnienia), etc. Wtedy jest to łatwo podpiąć pod każdy monitoring.

@kamil159: tak myślałem. Gdybys pokazał kod, byloby o wiele szybciej ;)

@kamil159: tak. Przydają się szczególnie przy redaktorze.

@kamil159: jak bardzo chcesz to możesz i settery testować, tylko zastanów się po co jest test - i czy to Ty jesteś potrzebny jemu czy on Tobie.

@Cheessys: Widzę progres. Chcę zobaczyć wszystko o postach, wchodzę w pakiet z postami i znajduję tylko to. Przy zależnościach między serwisami trzeba uważać tylko na cykle (nie może być referencji w dwie strony).
Jeszcze np. tagi zostały w user service i możesz się zastanowić, ile zależności między pakietami (serwisami z różnych pakietów) można zlikwidować.
Spotkasz jeszcze dużo projektów pisanych bez przemyślenia struktury (wielkie pakiety controller, services itp), ale zastanów sięPokaż całość

@Dominias: to pewnie problem z implementacją a nie testami :P

@mariusz-laszczka: piszesz ze junit a @AfterTest to chyba jest z testng. junit ma adnotacje @After

@mariusz-laszczka: tak jak pisał @kszych - w junit 4 masz po prostu After a od 5.0 masz AfterEach, spróbuj zamienić adnotację na junitową i jeszcze raz przetestować.

@damianbeat: A jak chcesz używać Jupiter API to chyba wystarczy dodać w Surefire depencency do jupiter-engine: https://www.petrikainulainen.net/programming/testing/junit-5-tutorial-running-unit-tests-with-maven/

@mariusz-laszczka: nie powinieneś ręcznie czyścić bazy, ustaw rollback'a po każdym teście.

A Twój problem może brać się np. z jakiegoś lock'a, etc. Ciężko stwierdzić bez całego kodu.

Metoda z adnotacja @After powinna kompensowac wszelkie @Before. W zalozeniu oczywiscie ze nie poleci zaden nieobsluzony runtime exception. Ewentualnie przedebugguj jakis przebieg testow zeby wysledzic co tam sie dzieje niedobrego (jakis conditional breakpoint np.). Jedyne co do odpalania testow JUnit, to szeregowanie testow jest przypadkowe, wiec nie mozna polegac na jakims specjalnym porzadku, by testy sie powodzily.

@mariusz-laszczka: na pierwszy rzut oka wygląda na coś, co można ogarnąć testami parametryzowanymi,
w JUnit<=4 @Parameters albo z dodatkowymi zależnościami @Parameterized, a w JUnit 5 strasznymi @TestFactory ( ͡° ͜ʖ ͡°)

Jak najepiej to zrobić?

@mariusz-laszczka: najlepiej to nie robić. Chcesz pisać adnotację + runnera per konkretny obiekt. Nie lepiej po prostu ustawiać te pola w trakcie instancjonowania obiektu?

@coll masz zależności między testami? może inicjalizuj co potrzeba za każdym razem w metodzie z adnotacją @Before

@damianbeat: Przecież driver.quit() zamyka aktywne okno przeglądarki, w którym śmiga webdriver. Nie wystarczy wykomentować tę linię?

@wykopowy_tester: @test_user: zastanawiam sie czy OP przypadkiem nie jest na etapie pisania kodu poruszającego sie po aplikacji, a do samych testów jeszcze nie doszedł ale użył juz metod setUp i tearDown. Chce pisać dalej kod ale przeglądarka mu sie zamyka.
@damianbeat: tak jak juz ktoś pisał, zakomentuj driver.quit() chociaż ja na takim etapie zawsze mam otwarta aplikacje w innym oknie i manualnie sie po niej poruszam

@coskoduje: Zerknij na początek np tu http://www.vogella.com/tutorials/Mockito/article.html