You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: build.gradle
+52-17Lines changed: 52 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -12,14 +12,6 @@ buildscript {
12
12
if (!no_nexus && (nexus_url =="null"|| nexus_user =="null"|| nexus_pw =="null")) {
13
13
thrownewGradleException("property no_nexus='false' (or not defined) but at least one of the properties nexus_url, nexus_user or nexus_pw is not configured. Please configure those properties!")
{Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.}
12
-
13
-
## Decision Drivers <!-- optional -->
9
+
When unit testing a service, the standard unit is usually the service class, simple as that. The test will mock out the layer underneath in this case the DAO/DAL layer and verify the interactions on it. Exact same thing for the DAO layer mocking out the interactions with the database (HibernateTemplate in this example) and verifying the interactions with that.
14
10
15
-
* {driver 1, e.g., a force, facing concern, …}
16
-
* {driver 2, e.g., a force, facing concern, …}
17
-
* … <!-- numbers of drivers can vary -->
11
+
This is a valid approach, but it leads to brittle tests adding or removing a layer almost always means rewriting the tests entirely. This happens because the tests rely on the exact structure of the layers, and a change to that means a change to the tests.
12
+
To avoid this kind of inflexibility, we can grow the scope of the unit test by changing the definition of the unit we can look at a persistent operation as a unit, from the Service Layer through the DAO and all the way day to the raw persistence whatever that is. Now, the unit test will consume the API of the Service Layer and will have the raw persistence mocked out in this case, the "templates.repository"
18
13
19
-
## Considered Options
14
+
## Decision Drivers
20
15
21
-
* {option 1}
22
-
* {option 2}
23
-
* {option 3}
24
-
* … <!-- numbers of options can vary -->
16
+
* Optimize testing effort
17
+
* Improve test quality
25
18
26
19
## Decision Outcome
27
20
28
-
Chosen option: "{option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
21
+
https://github.com/portainer/portainer
22
+
https://localhost:9443/
23
+
admin 12345678
29
24
30
25
### Positive Consequences <!-- optional -->
31
26
@@ -72,9 +67,8 @@ Chosen option: "{option 1}", because {justification. e.g., only option, which me
When unit testing a service, the standard unit is usually the service class, simple as that. The test will mock out the layer underneath in this case the DAO/DAL layer and verify the interactions on it. Exact same thing for the DAO layer mocking out the interactions with the database (HibernateTemplate in this example) and verifying the interactions with that.
78
71
79
-
This is a valid approach, but it leads to brittle tests adding or removing a layer almost always means rewriting the tests entirely. This happens because the tests rely on the exact structure of the layers, and a change to that means a change to the tests.
80
-
To avoid this kind of inflexibility, we can grow the scope of the unit test by changing the definition of the unit we can look at a persistent operation as a unit, from the Service Layer through the DAO and all the way day to the raw persistence whatever that is. Now, the unit test will consume the API of the Service Layer and will have the raw persistence mocked out in this case, the HibernateTemplate:
0 commit comments