Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Polish reference documentation

Browse Source
This commit is contained in:
Sam Brannen
2024-06-11 16:31:56 +02:00
parent 60b5bbe334
commit f481a4b60b
5 changed files with 83 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-mockitobean.adoc
View File

@@ -1,24 +1,24 @@
[[spring-testing-annotation-beanoverriding-mockitobean]]
= `@MockitoBean` and `@MockitoSpyBean`
`@MockitoBean` and `@MockitoSpyBean` are used on test class fields to override beans in
the test's `ApplicationContext` with a Mockito mock or spy, respectively. In the latter
case, the original bean definition is not replaced, but instead an early instance of the
bean is captured and wrapped by the spy.
`@MockitoBean` and `@MockitoSpyBean` are used on fields in test classes to override beans
in the test's `ApplicationContext` with a Mockito mock or spy, respectively. In the
latter case, the original bean definition is not replaced, but instead an early instance
of the bean is captured and wrapped by the spy.
By default, the annotated field's type is used to search for candidate definitions to
override. If multiple candidates match, the usual `@Qualifier` can be provided to
narrow the candidate to override. Alternatively, a candidate whose bean definition name
matches the name of the field will match.
By default, the annotated field's type is used to search for candidate bean definitions
to override. If multiple candidates match, `@Qualifier` can be provided to narrow the
candidate to override. Alternatively, a candidate whose bean definition name matches the
name of the field will match.
To use a by-name override rather than a by-type override, specify the `name` attribute
of the annotation.
[WARNING]
====
The qualifiers, including the name of the field are used to determine if a separate
`ApplicationContext` needs to be created. If you are using this feature to mock or
spy the same bean in several tests, make sure to name the field consistently to avoid
Qualifiers, including the name of the field, are used to determine if a separate
`ApplicationContext` needs to be created. If you are using this feature to mock or spy
the same bean in several tests, make sure to name the field consistently to avoid
creating unnecessary contexts.
====
@@ -26,14 +26,12 @@ Each annotation also defines Mockito-specific attributes to fine-tune the mockin
The `@MockitoBean` annotation uses the `REPLACE_OR_CREATE_DEFINITION`
xref:testing/testcontext-framework/bean-overriding.adoc#testcontext-bean-overriding-custom[strategy for test bean overriding].
If no definition matches, then a definition is created on-the-fly.
If no existing bean definition matches, a new bean definition is created on the fly.
The `@MockitoSpyBean` annotation uses the `WRAP_BEAN`
xref:testing/testcontext-framework/bean-overriding.adoc#testcontext-bean-overriding-custom[strategy],
and the original instance is wrapped in a Mockito spy.
It requires that exactly one candidate definition exists.
and the original instance is wrapped in a Mockito spy. This strategy requires that
exactly one candidate bean definition exists.
The following example shows how to use the default behavior of the `@MockitoBean` annotation:
@@ -44,8 +42,8 @@ Java::
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
class OverrideBeanTests {
@MockitoBean // <1>
private CustomService customService;
@MockitoBean // <1>
CustomService customService;
// test case body...
}
@@ -53,11 +51,11 @@ Java::
<1> Replace the bean with type `CustomService` with a Mockito `mock`.
======
In the example above, we are creating a mock for `CustomService`. If more that
one bean with such type exist, the bean named `customService` is considered. Otherwise,
the test will fail and you will need to provide a qualifier of some sort to identify which
of the `CustomService` beans you want to override. If no such bean exists, a bean
definition will be created with an auto-generated bean name.
In the example above, we are creating a mock for `CustomService`. If more than one bean
of that type exists, the bean named `customService` is considered. Otherwise, the test
will fail, and you will need to provide a qualifier of some sort to identify which of the
`CustomService` beans you want to override. If no such bean exists, a bean definition
will be created with an auto-generated bean name.
The following example uses a by-name lookup, rather than a by-type lookup:
@@ -68,14 +66,14 @@ Java::
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
class OverrideBeanTests {
@MockitoBean(name = "service") // <1>
private CustomService customService;
@MockitoBean(name = "service") // <1>
CustomService customService;
// test case body...
}
----
<1> Replace the bean named `service` with a Mockito `mock`.
<1> Replace the bean named `service` with a Mockito `mock`.
======
If no bean definition named `service` exists, one is created.
@@ -89,8 +87,8 @@ Java::
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
class OverrideBeanTests {
@MockitoSpyBean // <1>
private CustomService customService;
@MockitoSpyBean // <1>
CustomService customService;
// test case body...
}
@@ -98,10 +96,10 @@ Java::
<1> Wrap the bean with type `CustomService` with a Mockito `spy`.
======
In the example above, we are wrapping the bean with type `CustomService`. If more that
one bean with such type exist, the bean named `customService` is considered. Otherwise,
the test will fail and you will need to provide a qualifier of some sort to identify which
of the `CustomService` beans you want to spy.
In the example above, we are wrapping the bean with type `CustomService`. If more than
one bean of that type exists, the bean named `customService` is considered. Otherwise,
the test will fail, and you will need to provide a qualifier of some sort to identify
which of the `CustomService` beans you want to spy.
The following example uses a by-name lookup, rather than a by-type lookup:
@@ -112,12 +110,12 @@ Java::
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
class OverrideBeanTests {
@MockitoSpyBean(name = "service") // <1>
private CustomService customService;
@MockitoSpyBean(name = "service") // <1>
CustomService customService;
// test case body...
}
----
<1> Wrap the bean named `service` with a Mockito `spy`.
<1> Wrap the bean named `service` with a Mockito `spy`.
======

57
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-testbean.adoc
View File

@@ -1,30 +1,29 @@
[[spring-testing-annotation-beanoverriding-testbean]]
= `@TestBean`
`@TestBean` is used on a test class field to override a specific bean in the test's
`ApplicationContext` with an instance provided by a conventionally named static factory
method.
`@TestBean` is used on a field in a test class to override a specific bean in the test's
`ApplicationContext` with an instance provided by a factory method.
The associated factory method name is derived from the annotated field's name, or bean
name if specified. A `static` method with no argument that returns a type compatible
with the type of the bean to override is expected. To make things more explicit, or if
you'd rather use a different name, the annotation allows for a specific method name to
be provided.
The associated factory method name is derived from the annotated field's name, or the
bean name if specified. The factory method must be `static`, accept no arguments, and
have a return type compatible with the type of the bean to override. To make things more
explicit, or if you'd rather use a different name, the annotation allows for a specific
method name to be provided.
By default, the annotated field's type is used to search for candidate definitions to
override. If multiple candidates match, the usual `@Qualifier` can be provided to
narrow the candidate to override. Alternatively, a candidate whose bean definition name
matches the name of the field will match.
By default, the annotated field's type is used to search for candidate bean definitions
to override. If multiple candidates match, `@Qualifier` can be provided to narrow the
candidate to override. Alternatively, a candidate whose bean definition name matches the
name of the field will match.
To use a by-name override rather than a by-type override, specify the `name` attribute
of the annotation.
[WARNING]
====
The qualifiers, including the name of the field are used to determine if a separate
`ApplicationContext` needs to be created. If you are using this feature to override
the same bean in several tests, make sure to name the field consistently to avoid
creating unnecessary contexts.
Qualifiers, including the name of the field, are used to determine if a separate
`ApplicationContext` needs to be created. If you are using this feature to override the
same bean in several tests, make sure to name the field consistently to avoid creating
unnecessary contexts.
====
The following example shows how to use the default behavior of the `@TestBean` annotation:
@@ -36,25 +35,24 @@ Java::
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
class OverrideBeanTests {
@TestBean // <1>
private CustomService customService;
@TestBean // <1>
CustomService customService;
// test case body...
private static CustomService customService() { // <2>
static CustomService customService() { // <2>
return new MyFakeCustomService();
}
}
----
<1> Mark a field for overriding of the bean with type `CustomService`.
<1> Mark a field for overriding the bean with type `CustomService`.
<2> The result of this static method will be used as the instance and injected into the field.
======
In the example above, we are overriding the bean with type `CustomService`. If more that
one bean with such type exist, the bean named `customService` is considered. Otherwise,
the test will fail and you will need to provide a qualifier of some sort to identify which
of the `CustomService` beans you want to override.
In the example above, we are overriding the bean with type `CustomService`. If more than
one bean of that type exists, the bean named `customService` is considered. Otherwise,
the test will fail, and you will need to provide a qualifier of some sort to identify
which of the `CustomService` beans you want to override.
The following example uses a by-name lookup, rather than a by-type lookup:
@@ -65,17 +63,18 @@ Java::
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
class OverrideBeanTests {
@TestBean(name = "service", methodName = "createCustomService") // <1>
private CustomService customService;
@TestBean(name = "service", methodName = "createCustomService") // <1>
CustomService customService;
// test case body...
private static CustomService createCustomService() { // <2>
static CustomService createCustomService() { // <2>
return new MyFakeCustomService();
}
}
----
<1> Mark a field for overriding of the bean with name `service`.
<1> Mark a field for overriding the bean with name `service`, and specify that the
factory method is named `createCustomService`.
<2> The result of this static method will be used as the instance and injected into the field.
======