Consider the use of {@link ModelAndViewAssert} with JUnit 4 and TestNG.
- *
+ *
* @author Alef Arendsen
* @author Bram Smeets
* @author Sam Brannen
@@ -41,6 +41,7 @@ import org.springframework.web.servlet.ModelAndView;
* @see ModelAndViewAssert
* @deprecated as of Spring 3.0, in favor of using the listener-based test context framework
* ({@link org.springframework.test.context.junit38.AbstractJUnit38SpringContextTests})
+ * or {@link ModelAndViewAssert} with JUnit 4 and TestNG.
*/
@Deprecated
public abstract class AbstractModelAndViewTests extends TestCase {
diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml
index aac9ec8a7d5..03ea6fbb9ad 100644
--- a/spring-framework-reference/src/testing.xml
+++ b/spring-framework-reference/src/testing.xml
@@ -120,22 +120,22 @@
Spring MVCThe org.springframework.test.web package
- contains AbstractModelAndViewTests, which
- serves as a convenient base class for JUnit 3.8 based unit tests
- dealing with Spring MVC ModelAndView objects.
- When developing against Java 1.4 and higher (e.g., in combination with
- JUnit 4+, TestNG, etc.), you have the option of using the
- ModelAndViewAssert class (in the same package)
- to test your ModelAndView related
- functionality.
-
- Tip: depending on your testing environment, either extend
- AbstractModelAndViewTests or use
- ModelAndViewAssert directly and then use
- MockHttpServletRequest,
- MockHttpSession, etc. from the org.springframework.mock.web
- package to test your Spring MVC Controllers.
+ contains ModelAndViewAssert, which can be
+ used in combination with any testing framework (e.g., JUnit 4+,
+ TestNG, etc.) for unit tests dealing with Spring MVC
+ ModelAndView objects.
+
+
+ Unit testing Spring MVC Controllers
+
+ To test your Spring MVC Controllers,
+ use ModelAndViewAssert combined with
+ MockHttpServletRequest,
+ MockHttpSession, etc. from the org.springframework.mock.web
+ package.
+
+
@@ -175,7 +175,7 @@
or remote tests relying on deployment to an application server.
- Since Spring 2.5 unit and integration testing support is provided
+ Since Spring 2.5, unit and integration testing support is provided
in the form of the annotation-driven Spring TestContext Framework.
The TestContext Framework is agnostic of the actual testing framework
@@ -265,7 +265,7 @@
rebuild the application context before executing the next test.
- Context management and caching with the
+ See: context management and caching with the
TestContext Framework.
@@ -312,7 +312,7 @@
- Dependency Injection of test fixtures with the
+ See: dependency injection of test fixtures with the
TestContext Framework.
@@ -323,11 +323,11 @@
One common issue in tests that access a real database is their
affect on the state of the persistence store. Even when you're using a
development database, changes to the state may affect future tests.
- Also, many operations - such as inserting to or modifying persistent
+ Also, many operations - such as inserting or modifying persistent
data - cannot be performed (or verified) outside a transaction.
- The TestContext framework meets this need. By default, the
- framework will create and roll back a transaction for each
+ The TestContext framework addresses this issue. By default,
+ the framework will create and roll back a transaction for each
test. You simply write code that can assume the existence of a
transaction. If you call transactionally proxied objects in your
tests, they will behave correctly, according to their transactional
@@ -343,11 +343,14 @@
useful when you want a particular test to populate or modify the
database - the TestContext framework can be
instructed to cause the transaction to commit instead of roll back
- via the @TransactionConfiguration
- and @Rollback annotations.
+ via the
+ @TransactionConfiguration
+ and
+ @Rollback
+ annotations.
- Transaction management with the
+ See: transaction management with the
TestContext Framework.
@@ -382,12 +385,14 @@
- You may find it desirable to provide a custom, application-wide superclass for
- integration tests that provides further useful instance variables and
+
+ In addition, you may find it desirable to provide your own custom,
+ application-wide superclass for integration tests that provides
+ further useful instance variables and
methods specific to your project.
- Support classes for the
+ See: support classes for the
TestContext Framework.
@@ -458,6 +463,7 @@ public class CustomConfiguredApplicationContextTests {
passed or not).@DirtiesContext
+@Test
public void testProcessWhichDirtiesAppCtx() {
// some logic that results in the Spring container being dirtied
}
@@ -520,6 +526,7 @@ public class CustomConfiguredTransactionalTests {
the default rollback flag configured at the class level.
@Rollback(false)
+@Test
public void testProcessWithoutRollback() {
// ...
}
@@ -566,6 +573,7 @@ public void afterTransaction() {
context.
@NotTransactional
+@Test
public void testProcessWithoutTransaction() {
// ...
}
@@ -596,6 +604,7 @@ public void testProcessWithoutTransaction() {
entire class or individual methods.
@IfProfileValue(name="java.vendor", value="Sun Microsystems Inc.")
+@Test
public void testProcessWhichRunsOnlyOnSunJvm() {
// some logic that should run only on Java VMs from Sun Microsystems
}
@@ -607,6 +616,7 @@ public void testProcessWhichRunsOnlyOnSunJvm() {
Consider the following example:
@IfProfileValue(name="test-groups", values={"unit-tests", "integration-tests"})
+@Test
public void testProcessWhichRunsForUnitOrIntegrationTestGroups() {
// some logic that should run only for unit and integration test groups
}
@@ -706,6 +716,7 @@ public void testProcessWithOneSecondTimeout() {
fixture.
@Repeat(10)
+@Test
public void testProcessRepeatedly() {
// ...
}
@@ -894,16 +905,16 @@ public void testProcessRepeatedly() {
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class MyTest {
- @Autowired
- private ApplicationContext applicationContext;
+ @Autowired
+ private ApplicationContext applicationContext;
// class body...
}
- In contrast to the now deprecated JUnit 3.8 legacy support, test
- classes which use the TestContext framework do not need to override any
- protected instance methods to configure their
+ In contrast to the now deprecated JUnit 3.8 legacy class hierarchy,
+ test classes which use the TestContext framework do not need to override
+ any protected instance methods to configure their
application context. Rather, configuration is achieved merely by
declaring the @ContextConfiguration
annotation at the class level. If your test class does not explicitly
@@ -1079,7 +1090,7 @@ public class ExtendedTest extends BaseTest {
@RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
-@ContextConfiguration(locations={"daos.xml"})
+@ContextConfiguration("daos.xml")
public final class HibernateTitleDaoTests {
// this instance will be dependency injected @RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
-@ContextConfiguration(locations={"daos.xml"})
+@ContextConfiguration("daos.xml")
public final class HibernateTitleDaoTests {
// this instance will be dependency injected @RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
-@ContextConfiguration(locations={"daos.xml"})
+@ContextConfiguration("daos.xml")
public final class HibernateTitleDaoTests {
// this instance will be dependency injected @RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
-@ContextConfiguration(locations={"daos.xml"})
+@ContextConfiguration("daos.xml")
public final class HibernateTitleDaoTests {
// this instance will be dependency injected