I'm attempting to set up some Spring Boot JPA tests using:
package biz.ianw.coindatabase.test;
#RunWith(SpringRunner.class)
#DataJpaTest
public class DbTests {
#Test
public void test1() { ... }
}
I have a service class:
package biz.ianw.coindatabase.database;
//#Service
#Repository
#Transactional(readOnly=false)
public class CoinDbService { ... }
and an application:
package biz.ianw.coindatabase;
#SpringBootApplication
#Slf4j
#Configuration
#EnableEncryptableProperties
public class Main {
#Autowired
CoinDbService dbService;
... }
Starting the test gives the error:
Field dbService in biz.ianw.coindatabase.Main required a bean of type 'biz.ianw.coindatabase.database.CoinDbService' that could not be found.
This is, I assumed, something to do with the type of beans #DataJpaTest loads during startup:
#DataJpaTest can be used if you want to test JPA applications. By
default it will configure an in-memory embedded database, scan for
#Entity classes and configure Spring Data JPA repositories. Regular
#Component beans will not be loaded into the ApplicationContext.
I'm not quite sure why #Service classes should be considered as not required for JPA testing, but I tried to force the matter by annotating it as #Repository instead, but to no avail.
I can manually load the class with #Import(...) but it seems a tad hooky. Is there a better way to tell DataJpaTest what I need for testing?
I am quoting from DataJpaTest documentation where you can find the answer to your question.
Annotation that can be used in combination with
#RunWith(SpringRunner.class) for a typical JPA test. Can be used when
a test focuses only on JPA components.
Using this annotation will disable full auto-configuration and instead
apply only configuration relevant to JPA tests.
By default, tests annotated with #DataJpaTest will use an embedded
in-memory database (replacing any explicit or usually auto-configured
DataSource). The #AutoConfigureTestDatabase annotation can be used to
override these settings.
If you are looking to load your full application configuration, but
use an embedded database, you should consider #SpringBootTest combined
with #AutoConfigureTestDatabase rather than this annotation.
Related
Hello I am finding the solution for getting the bean instantiated given in #ContextConfiguration when we run the Vaadin test case with spring boot.
Here is some piece of the code which I have configured.
#WebAppConfiguration
#RunWith(JUnit4.class)
#ContextConfiguration(loader = AnnotationConfigContextLoader.class, classes = UIConfiguration.class)
public abstract class BaseTestCase extends TestBenchTestCase {
//code stuff
}
#Configuration
#PropertySource("classpath:META-INF/spring/application.properties")
#ComponentScan(basePackages = "com.ui", excludeFilters = #ComponentScan.Filter(value = Controller.class, type = FilterType.ANNOTATION))
#EnableAsync
#EnableI18N
public class UIConfiguration implements AsyncConfigurer {
//block of code
}
You should be able to use the ClassRule and Rule Spring provide if you do not want to use the SpringRunner
#ClassRule
public static final SpringClassRule SPRING_CLASS_RULE = new SpringClassRule();
#Rule
public final SpringMethodRule springMethodRule = new SpringMethodRule();
See the java doc for more details,
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/context/junit4/rules/SpringClassRule.html
SpringClassRule is a custom JUnit TestRule that supports class-level features of the Spring TestContext Framework in standard JUnit tests by means of the TestContextManager and associated support classes and annotations.
In contrast to the SpringJUnit4ClassRunner, Spring's rule-based JUnit support has the advantage that it is independent of any Runner and can therefore be combined with existing alternative runners like JUnit's Parameterized or third-party runners such as the MockitoJUnitRunner.
In order to achieve the same functionality as the SpringJUnit4ClassRunner, however, a SpringClassRule must be combined with a SpringMethodRule, since SpringClassRule only supports the class-level features of the SpringJUnit4ClassRunner.
I'm porting an app across from JDBC / REST to spring-data-rest and my one and only unit test with fails with the error
NoSuchBeanDefinitionException:
No qualifying bean of type 'com.xxx.repository.ForecastRepository' available
The app was retro-fitted with spring-boot just previously, and now I'm trying to put a new layer in place with spring-data-rest on top of spring-data-jpa.
I'm attempting to work out the correct Java-config according to
Custom Test Slice with Spring Boot 1.4
but I had to deviate from the idiomatic approach because
the #WebMvcTest annotation doesn't suppress the security module which causes the test to fail
the #MockMvcAutoConfiguration fails due to missing dependencies unless I specify #SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK) (see here)
#WebMvcTest and #SpringBootTest are mutually exclusive since they both specify #BootstrapWith and can't run together
So this is the closest I've got but Spring can't locate my #RepositoryRestResource repository:
Repository
#RepositoryRestResource(collectionResourceRel = "forecasts", path = "forecasts")
public interface ForecastRepository extends CrudRepository<ForecastExEncoded,
Long> {
JUnit Test
#RunWith(SpringRunner.class)
#SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK,
classes = {TestRestConfiguration.class})
public class ForecastRestTests {
#Autowired
private MockMvc mockMvc;
#Autowired
private ForecastRepository forecastRepository;
#Before
public void deleteAllBeforeTests() throws Exception {
forecastRepository.deleteAll();
}
#Test
public void shouldReturnRepositoryIndex() throws Exception {
mockMvc.perform(get("/")).andDo(print()).andExpect(status().isOk()).andExpect(
jsonPath("$._links.forecasts").exists());
}
}
Configuration
#OverrideAutoConfiguration(enabled = false)
#ImportAutoConfiguration(value = {
RepositoryRestMvcAutoConfiguration.class,
HttpMessageConvertersAutoConfiguration.class,
WebMvcAutoConfiguration.class,
MockMvcAutoConfiguration.class,
MockMvcSecurityAutoConfiguration.class
})
#Import({PropertySpringConfig.class})
public class TestRestConfiguration {}
Also tried...
I tried to configure the unit test with just #WebMvcTest and this #ComponentScan below from How to exclude AutoConfiguration from Spring Boot), in an attempt to simplify it all, however the excludeFilters had no effect.
#ComponentScan(
basePackages="com.xxx",
excludeFilters = {
#ComponentScan.Filter(type = ASSIGNABLE_TYPE,
value = {
SpringBootWebApplication.class,
JpaDataConfiguration.class,
SecurityConfig.class
})
})
I've set Spring's logging to trace because all I can do at this point is try to find clues as to what is happening from log output. So far though without any luck.
I can see in the logging that RepositoryRestConfiguration is loading, but obviously it isn't fed with the right info and I am unable to work out how that is done, after googling and pouring over the Spring docs and API. I think I must have read every relevant question here on SO .
Update 2016-11-16 10:00
One thing I see in the logs which concerns me is this:
Performing dependency injection for test context [DefaultTestContext#2b4a2ec7 [snip...]
classes = '{class com.xxx.TestRestConfiguration,
class com.xxx.TestRestConfiguration}',
i.e. the context lists the configuration class twice. I specified the config class (once only) on the #SpringBootTest#classes annotation. But if I leave off the #classes from the annotation, Spring Boot finds and pulls in all the config via the #SpringBootApplication class.
So is that a hint that I am specifying the configuration in the wrong place? How else would I do it?
After way too much time, I settled on this approach.
Custom Test Slice with Spring Boot 1.4 looked promising but I couldn't get anywhere with it.
While going over and over
Accessing JPA Data with REST
I realised I had to include the JPA setup because spring-data-rest is using them directly - no chance to mock them or run unit tests without an embedded database.
At least not as far as I understand it. Maybe it is possible to mock them and have spring-data-rest run on the mocks against test data, but I think spring-data-rest and spring-data are probably too tightly coupled.
So integration testing it must be.
In the Spring source code provided with the articles above
gs-accessing-data-rest/ApplicationTests.java
the logging shows Spring Boot pulling in the whole configuration for the application context.
So that my SpringBootApplication class is avoided and the security module isn't loaded up, I set up my tests like this:
#RunWith(SpringRunner.class)
#SpringBootTest
#ContextConfiguration(classes = {
JpaDataConfiguration.class,
TestJpaConfiguration.class,
TestRestConfiguration.class,
PropertySpringConfig.class})
public class ForecastRestTests {
#SuppressWarnings("SpringJavaAutowiringInspection")
#Autowired
private MockMvc mockMvc;
#Autowired
private ForecastRepository forecastRepository;
#Before
public void deleteAllBeforeTests() throws Exception {
forecastRepository.deleteAll();
}
#Test
public void shouldReturnRepositoryIndex() throws Exception {
mockMvc.perform(get("/")).andDo(print()).andExpect(status().isOk()).andExpect(
jsonPath("$._links.forecasts").exists());
}
}
with these configuration classes:
#Configuration
#EnableJpaRepositories(basePackages = {"com.bp.gis.tardis.repository"})
#EntityScan(basePackages = {"com.bp.gis.tardis.type"})
public class JpaDataConfiguration {
and
#Configuration
#OverrideAutoConfiguration(enabled = false)
#ImportAutoConfiguration(value = {
CacheAutoConfiguration.class,
JpaRepositoriesAutoConfiguration.class,
DataSourceAutoConfiguration.class,
DataSourceTransactionManagerAutoConfiguration.class,
HibernateJpaAutoConfiguration.class,
TransactionAutoConfiguration.class,
TestDatabaseAutoConfiguration.class,
TestEntityManagerAutoConfiguration.class })
public class TestJpaConfiguration {}
and
#Configuration
#OverrideAutoConfiguration(enabled = false)
#ImportAutoConfiguration(value = {
RepositoryRestMvcAutoConfiguration.class,
HttpMessageConvertersAutoConfiguration.class,
WebMvcAutoConfiguration.class,
MockMvcAutoConfiguration.class,
MockMvcSecurityAutoConfiguration.class
})
public class TestRestConfiguration {}
so the TL;DR summary is: use #ContextConfiguration to specify the configuration files that specify #OverrideAutoConfiguration and #ImportAutoConfiguration
Hi I'm trying to test my Service and Dao layers for a Java EE 7 application.
So I looking for testing solutions follow tutorials using Arquillian with junit test and wildfly remote dependence.
Dao and Service interfaces with relative implementations have been created, following my junit test with Arquillian:
#RunWith(Arquillian.class)
public class GenericServiceTest {
#Inject
private EmployeeService employeeService;
#Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap
.create(JavaArchive.class)
.addAsManifestResource("META-INF/persistence.xml",
"persistence.xml")
.addClasses(EmployeeDao.class, EmployeeDaoImpl.class,
EmployeeService.class, EmployeeServiceImpl.class,
Employee.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}
#Test
#Transactional
public void should_crud() {
// Gets all the objects
assertNotNull(employeeService);
Employee employee = employeeService.get(new Integer(1));
assertNotNull(employee);
}
}
Running class as JUnit Test it doesn't work with this error:
Caused by: java.lang.Exception: "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"
Test pass if any classes has been added to ShrinkWrap as following:
#RunWith(Arquillian.class)
public class GenericDaoTest {
#Inject
private EmployeeService employeeService;
#Deployment
public static JavaArchive createTestableDeployment() {
final JavaArchive jar = ShrinkWrap.create(JavaArchive.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
return jar;
}
#Test
public void should_crud() {
}
}
How can I create a working test using arquillian for Java EE 7 adding service class implementations?
And I have To add every Class and Intefaces that have to be called (for example all entities,dao etc classes) or only Service Interface and implementation Class?
Thanks a lot
Since you're developing a javaee application, I would suggest you to create a War archive instead of Jar.
You can add the whole package using
ShrinkWrap.addPackages(true, "com.yourpackage.name") so you don't have to add your classes independently.
If I understand the question correctly you want to test a war archive.
If this is the case you should change
return ShrinkWrap
.create(JavaArchive.class)
to
return ShrinkWrap
.create(WarArchive.class)
In addition you should add your persistence.xml file to the META-INF folder like:
.addAsResource("test-persistence.xml", "META-INF/persistence.xml")
If you want to use the annotation #Transactional in your tests, you need to add a few dependencies to your test scope. If you didn't add them yet you can read at http://arquillian.org/modules/transaction-extension/ what dependencies to add.
In order to get code coverage report, i instrument the #Decorator bean by cobertura maven plugin.
When running my unit test in OpenEJB container. The container reports some error during start up (new initial context).
Caused by: org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : MyDecorator, Name:null, WebBeans Type:DECORATOR, API Types:[org.apache.commo
ns.configuration.Configuration,net.sourceforge.cobertura.coveragedata.HasBeenInstrumented,org.apache.commons.configuration.AbstractConfiguration,MyDecorator,org.apache.commons.configuration.event.EventSource,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate at
tribute must implement all of the decorator decorated types, but decorator type interface net.sourceforge.cobertura.coveragedata.HasBeenInstrumented is not assignable from deleg
ate type of interface org.apache.commons.configuration.Configuration
Details:
I have one Decorator to be unit tested.
Something like
import org.apache.commons.configuration.AbstractConfiguration;
import org.apache.commons.configuration.Configuration;
#Decorator
public class MyDecorator extends AbstractConfiguration {
#Inject
#Delegate
private Configuration conf;
.....
}
After cobertura instrumented it, the code is like below:(I uncompile it)
import net.sourceforge.cobertura.coveragedata.HasBeenInstrumented;
#Decorator
public class MyDecorator extends AbstractConfiguration
implements HasBeenInstrumented
{
#Inject
#Delegate
private Configuration conf;
.....
}
As you can see, cobertura add one more interface for my decorator.
When OpenEJB load and deploy this instrumented class, a error is reported:
Caused by: org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : MyDecorator, Name:null, WebBeans Type:DECORATOR, API Types:[org.apache.commo
ns.configuration.Configuration,net.sourceforge.cobertura.coveragedata.HasBeenInstrumented,org.apache.commons.configuration.AbstractConfiguration,MyDecorator,org.apache.commons.configuration.event.EventSource,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate at
tribute must implement all of the decorator decorated types, but decorator type interface net.sourceforge.cobertura.coveragedata.HasBeenInstrumented is not assignable from deleg
ate type of interface org.apache.commons.configuration.Configuration
The error log say that the #Decorator and the #Delegate should implement the same types.
But after instrument, the to be tested class has one more interface.
Then i try to instrument the org.apache.commons.configuration.AbstractConfiguration and org.apache.commons.configuration.Configuration. (by instrument the commons-configuration-1.9.jar by cobertura command line)
And modify my code like:
#Decorator
public class MyDecorator extends AbstractConfiguration {
#Inject
#Delegate
private AbstractConfiguration conf;
.....
}
//I use AbstractConfiguration instead of Configuration, because the Configuration is an //interface which could not be instrumented.
After all of this,the problem is solved.
But it is not a good way to do this.
The root cause is maven cobertura plugin identify the class file is instrumented by adding an interface to the original class, i works for most of the cases.
But not for a #Decorator bean which running in an container.
Should i create an comments for maven-cobertura-plugin org?
Any one has some suggestion on how to unit test #Decorators.And easy to get coverage report?
May be my unit test is not implement in the good way, maybe the openejb is not good for this?
Normally how do you unit test your #Decorators?
Cobertura does not instrument interfaces. It is recommended the non-instrumented classes go in the classpath after the instrumented classes for that reason.
So when instrumenting, compile first with maven normally, then place yourself in the directory where the sourcecode of the classes you want to instrument exists, and then run the following command : mvn cobertura:instrument.
This will make cobertura instrument all the classes, and maven will automatically add the files not instrumented. the instrumented code will be at ".\target\generated-classes\cobertura".
You'll need to run the 'jar -cvf [name-of-jar].jar *', then you'll get your instrumented jar.
How would you go about integration testing a spring application that is annotation-configured and component-scanned and does not have an XML configuration at all? I'm hitting a wall with the need to replace production components with testing components without actually resorting to xml configuration or reflection injections to all the #autowired parts.
Example:
interface A {...}
#Component
class AImpl implements A {
...
}
interface B {...}
#Component
class BImpl implements B {
#Autowired A a;
...
}
interface C {...}
class CImpl implements C {
#Autowired B b;
...
}
then in my test I want to use ATestImpl, but I only have access to C (integration testing C).
How would you go about doing that?
Take advantage of #Primary annotation:
#Service
#Primary
public class TestA implements A {
//...
}
If there is more than one bean implementing A, Spring will prefer the one annotated with #Primary. If you place TestA class in /src/test/java, it will only be picked up during test execution, on normal context startup Spring won't see TestA and use only avaialble AImpl.
Use a dedicated spring context XML file where you override AImpl with an instance of ATestImpl. Of course, it uses XML, but I don't see any other solution (other than repackaging the application with your ATestImpl annotated class instead of the AImpl one)
The new Bean Profile features in Spring 3.1 address the need to swap injected components for testing by defining profiles e.g. test, production etc.
The link to the blog post is here. The Spring team have today released the second milestone release of Spring 3.1.
You can use a special component scan for your test, that exclude the "normal" class and add the test class.
If you have several different test classes, then they should not have a #Component Annotation (or #Service, ...). Instead they should be loaded by an XML Bean declaration. So you can have different XML files for different setups.
<context:component-scan base-package="com.queomedia.sgcrm.base">
<context:exclude-filter expression="com\.example\.AImpl" type="regex"/>
</context:component-scan>
<bean class="com.example.ATestImpl"/>
Using Spring annotation config classes, code the #Bean methods to interfaces. The prod config can perform a componentscan on the high-level package(s) to load the prod objects and the test configs can individually specify beans to return the test versions of your objects. This works very well for component testing where faking service calls and DAO objects is necessary.