root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions 6 Packages Projects Releases Wiki Activity

[SPR-8240][SPR-8401] formatting and polishing.

This commit is contained in:
Sam Brannen 2011-10-11 23:20:50 +00:00
parent 027c25d823
commit dc95e49c27
1 changed files with 56 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
spring-framework-reference/src/testing.xml
View File

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