ИМХО да они все еще актуальны.
С EJB3 вы можете тестировать свой EJB либо как обычный POJO, либо как управляемый компонент с использованием встроенного контейнера EJB.
То же самое и для JPA, вы можете либо встроить реализацию JPA для своего теста и использовать базу данных в памяти, либо полностью смоделировать уровень данных.
Для моего последнего проекта EJB я написал немного связующего кода для тестирования EJB, потому что встроенный контейнер EJB не был достаточно зрелым, но теперь я бы выбрал встроенный контейнер EJB + JUnit.
Несколько ресурсов
Но есть много других, которые легко найти
Для модульного тестирования вы можете использовать JUnit, TestNG и ваш любимый фреймворк для фиксации ( EasyMock , Mockito , PowerMock , JMockit , JMock ).
Для интеграционного тестирования вы можете запускать / останавливать встраиваемый контейнер (JBoss, OpenEJB, GlassFish v3) из ваших тестов. Или взгляните на Arquillian , недавно появившийся игрок для интеграционного тестирования приложений Java EE:
Миссия проекта Arquillian состоит в том, чтобы предоставить простые средства тестирования, которые разработчики могут использовать для создания широкий спектр интеграционных тестов для своих приложений Java (скорее всего, корпоративных приложений).Тестовый пример может быть выполнен в контейнере, развернут вместе с тестируемым кодом или путем координации с контейнером, выступая в качестве клиента для развернутого кода.
Чтобы избежать ненужного усложнения среды сборки разработчика, Arquillian прозрачно интегрируется со знакомыми средами тестирования (например, JUnit 4, TestNG 5), что позволяет запускать тесты с использованием существующих тестовых плагинов IDE, Ant и Maven без каких-либо надстроек.
Также проверьте Повышение тестируемости Java EE с помощью Arquillian 1.0.0 Alpha 1 Released и пространства Arquillan . Выглядит интересно ИМО.
Вы можете использовать Apache OpenEJB, который является облегченной реализацией EJB3.0, которая может быть встроена в TestNG.
Здесь вы можете найти пример кода, который использует OpenEJB, TestNG и jMockIt для модульного тестирования.
Один из вариантов - также использовать Spring, но, конечно, ваша архитектура будет также основана на Spring во время выполнения. Причина, по которой мне нравится Spring, заключается в том, что на этапе тестирования легко внедрить любые имитационные данные и объекты, поскольку вы можете указать в тестовом примере JUnit, какой файл контекста использовать:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath:test-context.xml"})
public class MyClassTest {
@Autowired
private MyClass myClass;
@Test
public void testMyMethod() {....}
Но если вы не хотите в любом случае используйте Spring, тогда это совершенно неактуально :) С другой стороны, потом очень легко отказаться от Spring.