7
Pracuję nad aplikacją Java EE 6. Kiedy zaczynałem, pisałem testy dla moich klas EJB przez ręczne tworzenie instancji EJB, a następnie ręczne dodawanie członków, które zwykle są dostarczane przez wstrzyknięcie zależności. Ponieważ aplikacja staje się bardziej skomplikowana, stwierdzam, że takie podejście po prostu jej nie ogranicza. Chciałbym móc uruchomić własny kontener EJB w strukturze testowej, aby mógł zarządzać moimi komponentami bean. Jaki jest najlepszy sposób podejścia do tego? Słyszałem o javax.ejb.embeddable.EJBContainer, czy są inne opcje?Strategie testowania EJB?
(Używam GlassFish 3 i budynek z Maven, jeśli czyni żadnej różnicy.)
Oczywiście testowanie POJO jest łatwiejsze. Ale nie mogę przenieść całej logiki z moich EJB i na niezależne klasy - gdybym mógł to zrobić, nie używałbym EJB w pierwszej kolejności. Działanie jako klient EJB na uruchomionym kontenerze jest dobrym opisem tego, co próbuję zrobić, próbuję po prostu znaleźć najlepszy sposób, aby to osiągnąć. –
Myślę, że miałeś rację, jeśli chodzi o testowanie wdrożonej aplikacji. Starałem się, aby EJBContainer pracował dla mnie (używając implementacji Glassfish-embedded), przeskoczył przez wiele kółek, aby uporać się z pracą, a następnie w końcu, gdy zorientowałem się, że usługa timera EJB (od której zależy moja aplikacja w kilku miejscach) nie został dostarczony. Zdałem sobie sprawę, że nawet jeśli uda mi się zbudować jakiś silnik do uruchomienia moich EJB-ów, to nigdy nie powieliłbym WSZYSTKICH warunków w prawdziwym pojemniku, więc byłby to bezużyteczny test. –
'Pamiętaj, że nie ma żadnej zasady, która mówi, że zautomatyzowane testy jednostkowe nie mogą wymagać działającego testowanego systemu. No cóż, tak naprawdę istnieją reguły, a takie testy nie są testami jednostkowymi, z definicji :) –