У меня есть проект Maven работает на Glassfish 3.0.1 с этих зависимостей в pom.xml:Использование Glassfish Embedded API в модульных тестов проекта Maven
...
<dependency>
<groupId>org.glassfish.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.0.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
...
Я пытался запустить юнит-тесты с использованием API встроенных в Glassfish API, как упоминалось в первой зависимости, но он дает мне ошибку каждый раз, когда я пытаюсь создать EJBContainer.
тестовый класс: журнал
...
@BeforeClass
public static void setUpClass() throws Exception {
EJBContainer ejbC = javax.ejb.embeddable.EJBContainer.createContainer();
}
...
ошибка:
javax.ejb.EJBException: No EJBContainer provider available
The following providers:
org.glassfish.ejb.embedded.EJBContainerProviderImpl
Returned null from createEJBContainer call.
at javax.ejb.embeddable.EJBContainer.reportError(EJBContainer.java:186)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:121)
at br.com.code.seuticket.sms.bean.GatewayBeanClickatellImplTest.setUpClass(GatewayBeanClickatellImplTest.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
ли кто-нибудь имеет опыт работы с модульного тестирования Maven проектов с Glassfish Embedded API?
arquilian хорошо, если цель состоит в том, чтобы сделать тест интеграции. Чтобы выполнить единичный тест, правильное решение издевается над другими слоями –
С такими инструментами, как Arquillian для управления жизненным циклом встроенного сервера приложений, Shrinkwrap для логической компоновки элементов приложения, в сочетании с базами данных в памяти, тестирование в эти дни разрушает старые барьеры, такие как единичные и интеграционные тесты. Возможно, нам нужен новый термин для них. «реальные тесты» или «полезные тесты» - это две возможности, которые приходят на ум: P –