Nauka testowania jednostkowego w Javie EE - jak sie za to zabrac

Witam,
Od jakiegos czasu pisze w Javie EE. Chce nauczyc sie pisania testow i po malu wchodzic w temat TDD.

Poszukuje na ten temat dobrych materialow, w szczegolnosci jak testowac jednostkowo bazy danych (wlasciwie warstwe DAO), JSF i EJB. Najlepiej przyklad gotowej aplikacji z testami.

Co nieco poczytalem i wiem, ze testy warstwy DAO nie sa oczywiste i bardzo wiele osob popelnia tu mnostwo bledow. Jednak aplikacje bazodanowe mimo to sa tworzenie z uzyciem TDD, a ja bardzo chce zaczac, tylko szukam punktu zaczepienia.

Czy warto czytac ksiazki o testach? Znajac zycie nie, ale moze jest tu jakis pozytywny wyjatek?

Pozdrawiam,

Testy jednostkowe nie obejmują działań na plikach, bazach danych, łączeniu z internetem. Obejmują one swoim zasięgiem tylko jedną klasę. Poczytaj o rodzajach testów (np. o integracyjnych). Jak chcesz zabrać się dobrze za testowanie to polecam: http://practicalunittesting.com/ Książka nie jest szczególnie droga, a bardzo dobrze wprowadza w tematykę testowania.

Zobacz również Arquillian

Takie testy, o których piszesz (tzn. gdzie łączysz się z bazą) są jak najbardziej poprawne, ale nie są to testy jednostkowe. Nie stosuje się ich również na początku (ciężko testować integracje pomiędzy warstwami, które nie istnieją). Testy jednostkowe mają być bardzo szybkie (kwestia milisekund/sekund), głównie dlatego, że odpalane są prawie non-stop (jest to jeden z etapów TDD, jeżeli w określonym momencie nie zrobisz wszystkich testów to "stoisz w miejscu"). Poczytaj o mockowaniu (to pozwoli dostarczyć "udawane" odpowiedzi z bazy danych).

Testować jednostkowo DAO mozesz, ale tylko z mockami. Testowanie np. czy jak wywołasz "save" na jakimś obiekcie encyjnym to się zapisze w bazie to są testy frameworka (np. hibernate) i tobie są one zbędne. Ty zakładasz że framework działa a testujesz tylko SWÓJ kod. Nic nie stoi na przeszkodzie żeby mockować EntityManagera / Session i sobie testować, ale pytanie czy w twoim DAO będzie wtedy co testować. Bo jeśli każda metoda to tylko delegacja wywołania metody na obiekcie z frameworka to nie warto.

czyli co? Tego czy procedura bazodanowa zwróci nam np określony wynik nie da się opędzić testami jednostkowymi? Jak wobec tego takie rzeczy testować?
Czy w ogóle się da?

btw również jestem kompletnym newbie w zakresie testów-te książki, które polecacie Tomka Kaczanowskiego są obie na tym samym poziomie? bo coś mi się obiło, że autor preferuje testng, a ja jednak wolałbym poczytać o junit.

@void-tec oczywiście że się da, ale po co chciałbyś to niby testować? o_O To przetestowali już autorzy biblioteki/frameworku i ty nie musisz się tym przejmować. A testujesz czy jak zrobisz Integer(1) to faktycznie będzie miał wartość 1? Albo czy jak dodasz coś do Map<> to czy faktycznie się dodało? Albo czy Set aby na pewno nie przechowuje duplikatów? Wątpię.

np to, czy procedura składowana na bd nie zmieniła typu i liczby argumentów, których potrzebuje. W mojej aplikacji część logiki jest na bazie danych a ja wołam ją przez hibernate, nie chce więc testować, czy biblioteka to dobrze robi, tylko czy nic od strony bd nie popsuło. W hibernate jak robię callablestatement to o tym, że coś nie działa dowiaduję się zwykle dopiero po uruchomieniu takiego kodu.

Drugi przykład (nie wiem czy dobry)-zapisuje obiekt, i chcę sprawdzić, czy obiekt, jaki bd przechowuje jest tym samym, który został zapisany, bo np mogłem zapomnieć anotacji na kolumnie

1. To jest test integracyjny a nie test jednostkowy. Możesz co prawda wykorzystać do niego JUnit, ale nie traktuj tego jako testu jednostowego.
2. Nie rozumiem. Jak obiekt nie jest encyjny to dostaniesz wyjątek już przy próbie jego zapisania.

Poczytaj o mockito. Za pomocą metody mock tworzysz instancję klasy lub interfejsu (szczególnie ważne). Wtedy ustalasz co wywołanie metody ma zwracać na zasadzie when(obiekt.mojaMetoda()).thenReturn("odpowiedz z bazy danych"). Wracając do tego co napisał @Shalom. Jeżeli jest to zwykła metoda wrapper (gdzie praktycznie oprócz przekazywania argumentów nie dzieje się nic innego) to nie ma wielkiego sensu w testowaniu takiej konstrukcji (chociaż fanatyk tdd prawodopobnie by się nie zgodził z tym stwierdzeniem).

Z tego co przeczytałem zrozumiałem, że taki test jest bezsensowny?

public class UserDaoTest {

	EntityManagerFactory emf;
	EntityManager em;
	UserDao dao;
	User user;
	
	@Before
	public void setUp() throws Exception {
		emf = Persistence.createEntityManagerFactory("Oracle");
		em = emf.createEntityManager();
		user = new User();
		dao = new UserDao(em);
	}

	@After
	public void tearDown() throws Exception {
		em.close();
		emf.close();
	}

	@Test
	public void testUserObject() {
		
		assertNotNull(user);
		
		user.setName("TEST");
		user.setCity("CITY");
		user.setEmail("EMAIL@EMAIL.COM");
		
		assertEquals(user.getName(), "TEST");
		assertEquals(user.getCity(), "CITY");
		assertEquals(user.getEmail(), "EMAIL@EMAIL.COM");
		
		assertNull(user.getLogin());
		assertNull(user.getCountry());
	}
	
	@Test
	public void testUserDao() {
		
		assertTrue(dao.save(user));
		
	}

}

Jako test jednostkowy? Tak. Zresztą samo assertNotNull(user); też nie ma większego sensu w teście, testowanie seterów i geterów też możesz sobie darować.

@olek1

1. Jeśli juz to to jest test integracyjny bo tworzysz połączenie do bazy a w teście jednostkowym powinieneś tu mieć mocka! Test jednostkowy testuje jedną klasę i jedną metodę, a ty tutaj wplatasz testowanie połączenia z bazą. Jak się ten test wysypie to skąd będziesz wiedział czy to błąd u ciebie w kodzie czy problem z bazą / dostawcą JPA? Nie będziesz wiedział, wiec to nie test jednostkowy.
2. Test jest bez sensu bo nie testuje właściwie ani trochę twojego kodu. Setterów / getterów nie liczę. Taki test to by mogli napisać twórcy tego ORMa którego uzywasz żeby sprawdzić czy działa ;]