Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
爱吃血肠
spring-framework
提交
edadb9ef
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,体验更适合开发者的 AI 搜索 >>
提交
edadb9ef
编写于
1月 23, 2019
作者:
S
Sam Brannen
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Remove obsolete PetClinic Example section of Testing chapter
Issue: #22288
上级
810b6154
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
1 addition
and
110 deletion
+1
-110
src/docs/asciidoc/testing.adoc
src/docs/asciidoc/testing.adoc
+1
-110
未找到文件。
src/docs/asciidoc/testing.adoc
浏览文件 @
edadb9ef
...
...
@@ -195,7 +195,6 @@ applications. It includes the following topics:
*
<<
integration
-
testing
-
annotations
>>
*
<<
testcontext
-
framework
>>
*
<<
spring
-
mvc
-
test
-
framework
>>
*
<<
testing
-
examples
-
petclinic
>>
...
...
@@ -3708,8 +3707,7 @@ a Hibernate-based `UserRepository`:
As
explained
in
<<
testcontext
-
tx
-
rollback
-
and
-
commit
-
behavior
>>,
there
is
no
need
to
clean
up
the
database
after
the
`
createUser
()`
method
runs
,
since
any
changes
made
to
the
database
are
automatically
rolled
back
by
the
`
TransactionalTestExecutionListener
`.
See
<<
testing
-
examples
-
petclinic
>>
for
an
additional
example
.
database
are
automatically
rolled
back
by
the
`
TransactionalTestExecutionListener
`.
[[
testcontext
-
tx
-
rollback
-
and
-
commit
-
behavior
]]
=====
Transaction
Rollback
and
Commit
Behavior
...
...
@@ -6136,113 +6134,6 @@ include::testing-webtestclient.adoc[leveloffset=+2]
[[testing-examples-petclinic]]
=== PetClinic Example
The PetClinic application, available on
https://github.com/spring-projects/spring-petclinic[GitHub], shows several features of
the Spring TestContext Framework in a JUnit 4 environment. Most test functionality is
included in the `AbstractClinicTests`, for which a partial listing follows:
====
[source,java,indent=0]
[subs="verbatim,quotes"]
----
import static org.junit.Assert.assertEquals;
// import ...
@ContextConfiguration <1>
public abstract class AbstractClinicTests extends AbstractTransactionalJUnit4SpringContextTests { <2>
@Autowired <3>
protected Clinic clinic;
@Test
public void getVets() {
Collection<Vet> vets = this.clinic.getVets();
assertEquals("JDBC query must show the same number of vets",
super.countRowsInTable("VETS"), vets.size()); <4>
Vet v1 = EntityUtils.getById(vets, Vet.class, 2);
assertEquals("Leary", v1.getLastName());
assertEquals(1, v1.getNrOfSpecialties());
assertEquals("radiology", (v1.getSpecialties().get(0)).getName());
// ...
}
// ...
}
----
<1> Load the application context from the default location: `AbstractClinicTests-context.xml`.
<2> This test case extends the `AbstractTransactionalJUnit4SpringContextTests` class, from
which it inherits configuration for Dependency Injection (through the
`DependencyInjectionTestExecutionListener`) and transactional behavior (through the
`TransactionalTestExecutionListener`).
<3> The `clinic` instance variable (the application object being tested) is set by
Dependency Injection through `@Autowired` semantics.
<4> The `getVets()` method shows how you can use the inherited `countRowsInTable()`
method to easily verify the number of rows in a given table, thus verifying correct
behavior of the application code being tested. This allows for stronger tests and
lessens dependency on the exact test data. For example, you can add additional rows in
the database without breaking tests.
====
Like many integration tests that use a database, most of the tests in
`AbstractClinicTests` depend on a minimum amount of data already being in the database
before the test cases run. Alternatively, you can populate the database within the test
fixture set up of your test cases (again, within the same transaction as the tests).
The PetClinic application supports three data access technologies: JDBC, Hibernate, and
JPA. By declaring `@ContextConfiguration` without any specific resource locations, the
`AbstractClinicTests` class has its application context loaded from the default location,
`AbstractClinicTests-context.xml`, which declares a common `DataSource`. Subclasses
specify additional context locations that must declare a `PlatformTransactionManager` and
a concrete implementation of `Clinic`.
For example, the Hibernate implementation of the PetClinic tests contains the following
implementation. For this example, `HibernateClinicTests` does not contain a single line
of code. We need only to declare `@ContextConfiguration`, and the tests are inherited
from `AbstractClinicTests`. Because `@ContextConfiguration` is declared without any
specific resource locations, the Spring TestContext Framework loads an application
context from all the beans defined in `AbstractClinicTests-context.xml` (that is, the
inherited locations) and `HibernateClinicTests-context.xml`, with
`HibernateClinicTests-context.xml` possibly overriding beans defined in
`AbstractClinicTests-context.xml`. The following listing shows the definition of the
`HibernateClinicTests` class:
====
[source,java,indent=0]
[subs="verbatim,quotes"]
----
@ContextConfiguration <1>
public class HibernateClinicTests extends AbstractClinicTests { }
----
<1> Load the application context from `AbstractClinicTests-context.xml` and `HibernateClinicTests-context.xml`.
====
In a large-scale application, the Spring configuration is often split across multiple
files. Consequently, configuration locations are typically specified in a common base
class for all application-specific integration tests. Such a base class can also add
useful instance variables (populated by Dependency Injection, naturally), such as a
`SessionFactory` in the case of an application that uses Hibernate.
As far as possible, you should have exactly the same Spring configuration files in your
integration tests as in the deployed environment. One likely point of difference concerns
database connection pooling and transaction infrastructure. If you are deploying to a
full-blown application server, you probably use its connection pool (available through
JNDI) and JTA implementation. Thus, in production, you can use a `JndiObjectFactoryBean`
or `<jee:jndi-lookup>` for the `DataSource` and `JtaTransactionManager`. JNDI and JTA are
not available in out-of-container integration tests, so you should use a combination such
as the Commons DBCP `BasicDataSource` and `DataSourceTransactionManager` or
`HibernateTransactionManager` for them. You can factor out this variant behavior into a
single XML file, having the choice between application server and a "`local`"
configuration separated from all other configuration, which will not vary between the
test and production environments. In addition, we recommend that you use properties files
for connection settings. See the PetClinic application for an example.
[[testing-resources]]
== Further Resources
See the following resources for more information about testing:
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录