JUnit, testowanie DAO

Cześć,

Chciałbym się spytać o wasze doświadczenia z testowania DAO.
Mam taki prosty test:

 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:test-application-context.xml"})
@Transactional
@TransactionConfiguration(defaultRollback = true)
public class UserHbnDaoTest {
    @Autowired
    private UserDao userDao; //czy może UserHbnDaoImpl ?

    @Test
    public void testAddUser() {
        User user = new User();
        user.setPassword("asdasdasd");
        user.setUsername("asd@asd.pl");

        user.setPerson(new Person("Asd", "Dsa"));

        userDao.add(user);
    }
}

Teraz pytanie jak przetestować metodę "add". Mógłbym oczywiście pobrać użytkownika z bazy i sprawdzić czy dane się zgadzają ale z tego co słyszałem to w takim przypadku testuję 2 metody w jednym teście co mija się z celem.
Jak wy rozwiązujecie takie podejście ?

Pozdrawiam.

A po co testujesz DAO ?

No żeby sprawdzić czy dane poprawie się zapisują :) To są chyba tak zwane testy integracyjne ale nie wiem do końca.

użyj mocków do testów dao. Po coś one zostały wymyślone.

//given
long rowCount = countRows(Customer.class)

//when
dao.persist(customer);

//then
long currentRowCount = countRows(Customer.class)
assertThat(currentRowCount).isEqualsTo(rowCount +1)

Dalej nie rozumiem na co testowac dao

Dlaczego testy integracyjne DAO nie maja sensu? Oczywiscie sie nie zgadzam. Wszystko zalezy od kontekstu.

Moim zdaniem maja, poniewaz:

• pozwalaja sprawdzic np. poprawnosc constraints w JPA (Bean Validation): bardzo czesto zdarzaja sie tu problemy, w szczegolnosci rozjazdy miedzy baza, a mapowaniem
• pozwalaja sprawdzic np. poprawnosc polaczenia z bazy i w ogolnosci konfiguracji: oczywiscie jest to kosztowne i powinno byc robione przy specjalnie przygotowanym srodowisku np. bazie w srodowisku CI (przez co czesto nie stac nas na testy integracyjne i testujemy jednostkowo, wtedy generalnie nie testujemy DAO)

Czy jak bedziecie mieli bardzo skomplikowane, dynamiczne zapytanie, ktore chcecie wytestowac integracyjnie majac np. specjalnie przygotowane srodowisko z danymi testowymi do tego celu to tez napiszecie, ze nie ma to sensu bo 'DAO sie nie testuje'?

Moim zdaniem ludzie maja tendencje do powtarzania zaslyszanych tekstow bez glebszego zrozumienia, co utrudnia wylapywanie wartosciowych postow na forach.

Testem DAO moze byc np. integracyjny test WebService, ktory np. zapisuje dane do specjalnie przygotowanej bazy, a nastepnie je usuwa (moze byc nawet z SoapUI).

Moim zdaniem nie ma sensu uruchamiac tego typu w srodowisku deweloperskim (w przeciwienstwie do unit testow przy kazdym uruchomieniu, ktore sa szybkie i zadzialaja niezaleznie od srodowiska).

Wada testow integracyjnych jest generalnie ich kosztownosc (czas wykonania i koniecznosc utrzymywanie srodowiska, w ktorym maja zadzialac), dlatego czesto ich sie po prostu nie wykonuje.

Jeszcze bardziej krzywa rade wydaje mi sie polecania uzycia mockow do testu DAO. Oczywiscie lepszy wydaje mi sie test integracyjny, bo testujemy rzeczywiste rozwiazania, a nie dzialanie frameworka mockujacego. Oczywiscie placimy za to wysoka cene bo testy integracyjne sa drogie.

Mocki sa swietne do logiki i testow w izolacji service, gdzie DAO sie mockuje, ale nie testuje (aby mozna bylo przetestowac interakcje miedzy testowanym obiektem (system under test), a jego zaleznosciami i dzialanie kodu logiki niezwianej z kontenerem EJB / Spring).

Jednostkowo testuje się generalnie swój kod. Jeśli jedyne co masz w tym DAO to ''session.saveOrUpdate(...)" to właściwie nie ma czego testować ;) W DAO raczej nie ma zadnej logiki, a przynajmniej być nie powinno więc nie bardzo jest co testować.

Jeśli chcesz pisać testy integracyjne to je pisz z użyciem serwisów/logiki biznesowej.</quote> Ja osoboście servicy testuje jednostkowo, nie integracyjne bo jest to tanie. Muszę wiedzieć jednak jakie interakcje lub assercje testuje (co chcę uzyskać). I używam Mockito, DAO sobie mockując. Gdybym prostą logikę testował integracyjnie (czyli za każdym razem uruchamiał kontener) mocno wydłużyłbym czas uruchomienia aplikacji, co moim zdaniem jest niekorzystne i dopuszczlane jedynie na żądanie. A tak testy jednostkowe idą jak błyskawica, przy każdym budowaniu aplikacji. Szkoda to psuć testami integracyjnymi.

Z kolei testy integranuje planuje wykorzystywać, gdy starczy czasu i problem będzie tego warty:

• testów warunków brzegowych w bean validation (czasem z zapisem zapytań), zwykle z testem constraintów w środowisku bazy danych (szczególnie jak pojawiły się bugi, jak wszystko było ok raczej nie mam zamiaru ponosić kosztu utrzymywanie testu integracyjnego)
• dziwnych selectów w SQL (np. dynamiczne query Criteria Query), ale muszę mieć gotowe dane i je utrzymywać (to jest drogie, ale czasem warto!)
• testu service połączonych z DAO w pewnych szczególnych przypadkach, gdzie unit test nie da rady i test w izolacji nie ma sensu (jednak nie będę tego uruchamiał przy każdym budowaniu, bo kontener wymaga trochę czasu na załadowanie): czyli najlepiej za jednym zamachem integrascyjnie i WebService i DAO