Search:

The problem is that your service is proxied, likely since the service or its methods are annotated with @Transactional, @Cacheable, or similar. Thus you are passing the proxy to Mockito instead of...

The JndiPropertySource gets registered automatically in StandardServletEnvironment which is used by GenericWebApplicationContext which in turn is used by the Spring TestContext Framework when loading...

The Spring TestContext Framework historically has not provided support for loading a WebApplicationContext in integration tests.

This support was first introduced in Spring Framework 3.2. See the...

You are definitely operating under false assumptions. The context will not get cleared after each test. In fact, exactly the opposite happens: contexts are cached by default.

Have you ever read...

Having you considered using the jdbc namespace for populating the database as the ApplicationContext is loaded?

If you need more control than you get from the XML namespace, you can simply use the...

Hi Giovanni,

Someone has already requested this feature in SPR-7873.

So feel free to watch SPR-7873, vote for it, and/or add your comments there.

Regards,

Sam

markuse1501,

As an aside, you can simplify your test configuration as follows:



@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = DataSourceConfig.class)...

FYI:

This issue has been resolved.

Specifically, as of Spring 3.2 RC1, you can annotate your test class with @WebAppConfiguration to instruct the Spring TestContext Framework to load a...

Hi Manuel,

Have you looked at the following method in JdbcTemplate?


org.springframework.jdbc.core.JdbcTemplate.update(String, PreparedStatementSetter)

You should be able to write a custom...

Hi guys,

The following are open JIRA issues related to this topic. Feel free to watch them.


ApplicationContext fails to load in tests using Java-based config and WebMvcConfigurationSupport
...

Hi Tom,

It's likely just a small configuration issue since Spring cannot find your UnsecureService bean in the application context loaded for your test.

You list excerpts from two application...

Hi Coenos,

By default, the Spring TestContext Framework assumes that resource locations are in the classpath. If you want to reference an XML configuration file in the filesystem, you'll need to...

Hi direm,

I'm glad you got your test working.

Here are a few tips...


Do not declare the siteMapUnmarshallerServiceImplTest bean. Test classes should never be configured in your Spring...

Also, autowiring private fields in your components (e.g., in EmailAddressServiceImpl) is a bad practice regarding testability.

Best practices include either autowiring a constructor or setter...

Hi seifi,

First, please wrap your code in [ CODE ][/ CODE ] tags (not in QUOTE tags) so that people can read it.

Second, you cannot just annotate a method with @Bean directly in your test...

The JUnit 3.8 support is entirely deprecated in Spring 3.1. You should therefore use either JUnit 4 or TestNG instead.

Regarding the old setComplete() and endTransaction() methods, those methods...

Hi Sudhcha,

FYI: your configuration is overkill. You should practically never need to implement ApplicationContextAware in a test class. Instead, you should just autowire your test dependencies --...

Hi Franck,

There's actually no reason to implement a custom JMS ExceptionListener. CachingConnectionFactory already implements the JMS ExceptionListener interface, and CachingConnectionFactory's...

The util namespace was introduced in Spring 2.0. See the util schema section of the reference manual for details.

Regards,

Sam

If that's how you got it to work, it may have been a caching problem involving classpath resources. Have you tried refreshing and cleaning your project (i.e., instructing your IDE to rebuild your...

Are you explicitly flushing and clearing your Session/EntityManager?

The section from the reference manual that you're referring to only applies to the following annotations:


@IfProfileValue
@ProfileValueSourceConfiguration
@ExpectedException
@Timed
...

Are you using Spring 2.5.x or Spring 3.0.x?

FYI: @DirtiesContext is not supported at the class level in Spring 2.5. I didn't add class-level support until 3.0. In Spring 3.0 @DirtiesContext...

@Configurable has zero effect on a test class. So just remove it!

See the following JIRA issue and related forum threads (i.e., the links in the JIRA issue comments): https://jira.springsource.org/browse/SPR-5243

Regards,

Sam