Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
爱吃血肠
spring-framework
提交
dc95e49c
S
spring-framework
项目概览
爱吃血肠
/
spring-framework
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
S
spring-framework
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
dc95e49c
编写于
10月 11, 2011
作者:
S
Sam Brannen
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
[SPR-8240][SPR-8401] formatting and polishing.
上级
027c25d8
变更
1
显示空白变更内容
内联
并排
Showing
1 changed file
with
57 addition
and
40 deletion
+57
-40
spring-framework-reference/src/testing.xml
spring-framework-reference/src/testing.xml
+57
-40
未找到文件。
spring-framework-reference/src/testing.xml
浏览文件 @
dc95e49c
...
...
@@ -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>
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>
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
<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"
>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录