Testy JUnit z Hibernate/JPA

0

Witam, od niedawna zacząłem pisać programy z użyciem Hibernate/JPA i jak na razie wszystko szło spoko lecz chciałem zacząć pisać testy do metod, które używają połączenia z bazą danych i tu pojawił mi się problem bo nie wiem z której strony się za to zabrać. Mam klasę public class DatabaseFunction implements DatabaseFunctionInterface {
private EntityManager entityManager;
public DatabaseFunction(EntityManager entityManager) {
this.entityManager = entityManager;
}

public Maker returnMaker(String makerName) {
	Maker maker;
	try{
	 maker = entityManager.createQuery("select e from Maker e where e.makerName = :makerName", Maker.class)
			.setParameter("makerName", makerName).getSingleResult();
	}catch(NoResultException e){
		return null;
	}
	return maker;
}

}

Metoda zwraca mi po prostu obiekt klasy Maker z bazy danych. Teraz chciałbym przetestować tą metodę ale nie mam pojęcia jak się zabrać to tego. Czy mógłby mi ktoś pomóc z tym? Próbowałem pisać coś takiego ale nie działa gdyż to nadpisuje mi moją baze danych <code> public class DatabaseFunctionTest {
	static EntityManager entityManager;
	static EntityManagerFactory entityManagerFactory;
	DatabaseFunction function;
	@BeforeClass
	static public void setUp(){
		DatabaseFunction function = new DatabaseFunction(entityManager);
		entityManagerFactory = Persistence.createEntityManagerFactory("myDatabase");
		entityManager = entityManagerFactory.createEntityManager();
	
	}
	//ReturnMakerAllTest
	//================================================================================	
	@Test
	public void returnMakerTest() {
		Maker maker = new Maker();
		maker.setMakerName("Hortex");
		entityManager.getTransaction().begin();
		entityManager.persist(maker);
		entityManager.getTransaction().commit();
		String makerName = ("Hortex");
		Maker maker2 = function.returnMaker(makerName);
		System.out.println(maker2.getMakerName());
		Assert.assertNotNull(maker2);

		
	}
	@AfterClass 
	static public void closeConnection(){
		entityManager.close();
		entityManagerFactory.close();
	}

Z góry dzięki za pomoc:)

0

Zacznij od pytania: co chcesz w ogóle przetestować? Zwyczajowo takie testy pisze się w oparciu o Mocki, tzn tworzysz mock object dla twojego entity managera i programujesz jego zachowanie, tak żeby w ogóle nie korzystać z tej bazy danych. Niemniej w twoim przypadku niewiele będzie można tu sprawdzić akurat i taki test wygodniej byłoby zrobić za pomocą testu integracyjnego - tzn odpalić entity managera dla bazy testowej (może jakiś HSQL na przykład).

4

Nie no @Shalom gościu chce przetestować zapytania w DAO a ty z mockowaniem wyskakujesz.
Generalnie do testowania DAO, czyli tych operacji zapisu/odczytu danych z bazy to testy integracyjne (i tutaj najpopularniejsze podejście arquillian + jakaś lekka baza h2 czy hsql).
Ale podejście z testami jednostkowymi nie jest złe. Też podpina się osobną bazę tak jak w przypadku wyżej i na niej wywołuje wykonywane metody. Ma to swoje plusy, lekkość takich testów, czas ich odpalania i łatwość konserwacji (oczywiście nie są to testy integracyjne tylko jednostkowe) ale do przetestowania jakiś prostych operacji zapisu/update na encji czy jakiś prostych zapytań to moim zdaniem bardziej praktyczne. Nie każdy system to wielomodułowa kobyła.

A jak Ty myślisz mój miszczu?! :)

1

Arquillian raczej. Kilka razy sprawdził mi sie DBunit (choć to staroć i dużo się trzeba nagrzebać, żeby uruchomić). A ostation ostatnio używam ręcznie zrobionych potworków do Unit testów z Bazą SQL. (Nie trzeba się ... aż tak dużo napisać). (Dodatkowo testują mi też poprawność migracji zrobionych na FlyWayu). Baza w pamięci HSQLDB (przy czym oczywiście są wypadki, że działa inaczej niż Oracle - albo nie wspiera pewnych elementów składni (dla JPA to nie problem, gorzej właśnie dla jakiś migracji w gołym SQL).

Testowanie na Mockach oczywiście nie ma sensu , choć zapewne ma pewien walor humorystyczny, można totalnie porozwalać Query, rozwalić schemat strukturę bazy danych itp. a testy nadal będą na zielono (ile razy to zobacze to zawsze mam cały dzień śmiechu :-) ).

Ogólnie - testowanie klasycznych perzystencji bazodanowych opartych o SQL (a także NoSQL) to i tak pewna męczarnia (powolne, nie są 100% pewne, i trudne w utrzymaniu (najgorsze jest zwykle zarządzanie danymi testowymi w insertach, xmla-ch, jsonach...)).

Więc tu mam radę - nie używać baz danych (i życie staje się prostsze).

A dla niedowiarków polecam moje wykłady -> najblizszy - w Polsce na JDD w Krakowie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1