[SPR-8240][SPR-8401] formatting and polishing.
This commit is contained in:
Sam Brannen
parent
027c25d823
commit
dc95e49c27
|
|
@ -1283,7 +1283,7 @@ public class OrderServiceTest {
|
|||
production configuration you will define either a set of XML
|
||||
resource locations or a set of
|
||||
<interfacename>@Configuration</interfacename> classes that your
|
||||
production <interfacename>ApplicationContext</interfacename> will
|
||||
production <interfacename>ApplicationContext</interfacename> will be
|
||||
loaded from, but you still have the freedom to include or import the
|
||||
other type of configuration.</para>
|
||||
</section>
|
||||
|
|
@ -1362,22 +1362,26 @@ public class ExtendedTest extends BaseTest {
|
|||
<title>Context configuration with environment profiles</title>
|
||||
|
||||
<para>Spring 3.1 introduces first-class support in the framework for
|
||||
the notion of environments and profiles (a.k.a., bean definition
|
||||
profiles), and integration tests can now be configured to activate
|
||||
particular bean definition profiles for various testing scenarios.
|
||||
This is achieved by annotating a test class with the new
|
||||
@ActiveProfiles annotation and supplying a list of profiles that
|
||||
should be activated when loading the ApplicationContext for the
|
||||
test.</para>
|
||||
the notion of environments and profiles (a.k.a., <emphasis>bean
|
||||
definition profiles</emphasis>), and integration tests can now be
|
||||
configured to activate particular bean definition profiles for
|
||||
various testing scenarios. This is achieved by annotating a test
|
||||
class with the new <interfacename>@ActiveProfiles</interfacename>
|
||||
annotation and supplying a list of profiles that should be activated
|
||||
when loading the <interfacename>ApplicationContext</interfacename>
|
||||
for the test.</para>
|
||||
|
||||
<note>
|
||||
<para>@ActiveProfiles may be used with any implementation of the
|
||||
new SmartContextLoader SPI, but @ActiveProfiles is not supported
|
||||
with implementations of the older ContextLoader SPI.</para>
|
||||
<para><interfacename>@ActiveProfiles</interfacename> may be used
|
||||
with any implementation of the new
|
||||
<interfacename>SmartContextLoader</interfacename> SPI, but
|
||||
<interfacename>@ActiveProfiles</interfacename> is not supported
|
||||
with implementations of the older
|
||||
<interfacename>ContextLoader</interfacename> SPI.</para>
|
||||
</note>
|
||||
|
||||
<para>Let's take a look at some examples with XML configuration and
|
||||
@Configuration classes.</para>
|
||||
<interfacename>@Configuration</interfacename> classes.</para>
|
||||
|
||||
<programlisting language="xml"><!-- app-config.xml -->
|
||||
<beans xmlns="http://www.springframework.org/schema/beans"
|
||||
|
|
@ -1433,25 +1437,33 @@ public class TransferServiceTest {
|
|||
}
|
||||
}</programlisting>
|
||||
|
||||
<para>When TransferServiceTest is run, its ApplicationContext will
|
||||
be loaded from the app-config.xml configuration file in the root of
|
||||
the classpath. If you inspect app-config.xml you'll notice that the
|
||||
accountRepository bean has a dependency on a dataSource bean;
|
||||
however, dataSource is not defined as a top-level bean. Instead,
|
||||
dataSource is defined twice: once in the production profile and once
|
||||
in the dev profile.</para>
|
||||
<para>When <classname>TransferServiceTest</classname> is run, its
|
||||
<interfacename>ApplicationContext</interfacename> will be loaded
|
||||
from the <filename>app-config.xml</filename> configuration file in
|
||||
the root of the classpath. If you inspect
|
||||
<filename>app-config.xml</filename> you'll notice that the
|
||||
<varname>accountRepository</varname> bean has a dependency on a
|
||||
<varname>dataSource</varname> bean; however,
|
||||
<varname>dataSource</varname> is not defined as a top-level bean.
|
||||
Instead, <varname>dataSource</varname> is defined twice: once in the
|
||||
<emphasis>production</emphasis> profile and once in the
|
||||
<emphasis>dev</emphasis> profile.</para>
|
||||
|
||||
<para>By annotating TransferServiceTest with @ActiveProfiles("dev")
|
||||
we instruct the Spring TestContext Framework to load the
|
||||
ApplicationContext with the active profiles set to {"dev"}. As a
|
||||
result, an embedded database will be created, and the
|
||||
accountRepository bean will be wired with a reference to the
|
||||
development DataSource. And that's likely what we want in an
|
||||
integration test.</para>
|
||||
<para>By annotating <classname>TransferServiceTest</classname> with
|
||||
<interfacename>@ActiveProfiles("dev")</interfacename> we instruct
|
||||
the Spring TestContext Framework to load the
|
||||
<interfacename>ApplicationContext</interfacename> with the active
|
||||
profiles set to <literal>{"dev"}</literal>. As a result, an embedded
|
||||
database will be created, and the
|
||||
<varname>accountRepository</varname> bean will be wired with a
|
||||
reference to the development
|
||||
<interfacename>DataSource</interfacename>. And that's likely what we
|
||||
want in an integration test.</para>
|
||||
|
||||
<para>The following code listings demonstrate how to implement the
|
||||
same configuration and integration test but using @Configuration
|
||||
classes instead of XML.</para>
|
||||
same configuration and integration test but using
|
||||
<interfacename>@Configuration</interfacename> classes instead of
|
||||
XML.</para>
|
||||
|
||||
<programlisting language="java">@Configuration
|
||||
@Profile("dev")
|
||||
|
|
@ -1510,30 +1522,35 @@ public class TransferServiceTest {
|
|||
}</programlisting>
|
||||
|
||||
<para>In this variation, we have split the XML configuration into
|
||||
three independent @Configuration classes:</para>
|
||||
three independent <interfacename>@Configuration</interfacename>
|
||||
classes:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>TransferServiceConfig: acquires a dataSource via
|
||||
dependency injection using @Autowired</para>
|
||||
<para><classname>TransferServiceConfig</classname>: acquires a
|
||||
<varname>dataSource</varname> via dependency injection using
|
||||
<interfacename>@Autowired</interfacename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>StandaloneDataConfig: defines a dataSource for an embedded
|
||||
database suitable for developer tests</para>
|
||||
<para><classname>StandaloneDataConfig</classname>: defines a
|
||||
<varname>dataSource</varname> for an embedded database suitable
|
||||
for developer tests</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>JndiDataConfig: defines a dataSource that is retrieved
|
||||
from JNDI in a production environment</para>
|
||||
<para><classname>JndiDataConfig</classname>: defines a
|
||||
<varname>dataSource</varname> that is retrieved from JNDI in a
|
||||
production environment</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>As with the XML-based configuration example, we still annotate
|
||||
TransferServiceTest with @ActiveProfiles("dev"), but this time we
|
||||
specify all three configuration classes via the
|
||||
@ContextConfiguration annotation. The body of the test class itself
|
||||
remains completely unchanged.</para>
|
||||
<classname>TransferServiceTest</classname> with
|
||||
<interfacename>@ActiveProfiles("dev")</interfacename>, but this time
|
||||
we specify all three configuration classes via the
|
||||
<interfacename>@ContextConfiguration </interfacename>annotation. The
|
||||
body of the test class itself remains completely unchanged.</para>
|
||||
</section>
|
||||
|
||||
<section id="testcontext-ctx-management-caching">
|
||||
|
|
|
|||
Loading…
Reference in New Issue