catalogue
1. Shortest path first principle
2. Principle of first declaration
3. Exclude dependencies and lock versions
I Maven engineering test
1. Test overview
Testing is to evaluate the written code before delivery, which is divided into black box test and white box test:
- Black box test: you don't need to write code. Give the input value to see whether the program can output the expected value.
- White box test: need to write code. Pay attention to the specific execution process of the program.
Unit test refers to the inspection and verification of the smallest testable unit in the software,
Java
Unit test refers to the function of a class. Unit testing is carried out in the process of software development
At the lowest level of testing activities, independent units of software will be separated from other parts of the program
The test is carried out in the absence of.
Junit
yes
Java
The unit test framework of programming language is used to write and run repeatable automatic tests. It belongs to white box test from classification. In fact, it is to test whether each method is easy to use.
2.Junit usage steps
Introducing dependencies into Maven project
<dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency>
After adding the above code, maven will automatically import the corresponding jar package. It can be seen that maven is really convenient!
Define the class to be tested
We define a calculator tool class.
package com.first.util;
public class Calculator {
//addition
public int add(int a,int b){
return a+b;
}
//division
public int div(int a,int b){
return a/b;
}
}
Test the defined class
1
- Create src/test/java package and set the modified package as test package.
- Create the package of the test class in src/test/java, and the package name is generally consistent with that of the tested package.
- Define the Test class. The class name is generally the tested class + Test
- Write test methods in test classes.
Test class:
package com.first.util;
import org.junit.Test;
public class CalculatorTest {
/*
The test method can be operated independently (directly click the green switch on the left)
1.The method name is generally test + the name of the tested method
2.Add @ Test above the method
3.The test method has no parameters and return values
*/
@Test
public void testAdd(){
Calculator calculator=new Calculator();
int add=calculator.add(1,2);
System.out.println(add);
}
@Test
public void testDiv(){
Calculator calculator=new Calculator();
int div=calculator.div(2,0);
System.out.println(div);
}
}
Project structure:
3.Junit result judgment
Click the triangle next to the test method to run the test method. If a green check appears, it proves that the method can operate normally; If a red exclamation mark appears, the proof method throws an exception and needs to be repaired
Change the method.
You can also execute the test command
You can also click test in Lifecycle
Of course, it doesn't mean that the method must have no problem if it can run normally. It is also possible that the result of the method is inconsistent with the expected result. At this time, assertion operation is required.
Modify the testAdd method:
If the expected result is inconsistent with the actual result, an error will be reported
@Test
public void testAdd(){
Calculator calculator=new Calculator();
int add=calculator.add(1,2);
//System.out.println(add);
/*
Assert
Parameter 1: expected result parameter 2: actual result
*/
Assert.assertEquals(4,add);
}add is 3, but the expected result is 4. The error is as follows:
If the assertion matches, no error will be reported.
4.@Before,@After
@Before modification pre method
@After modification post method
In the test class,
@Before
The modification method will be before the test method
Automatic execution
，@After
The modified method will be executed after the test method
Automatic execution
. After learning
In, we can set the pre method to obtain resources and the post method to release resources.
Modify the above method so that testAdd does not report an error, and then execute testAdd
package com.first.util;
import org.junit.After;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
public class CalculatorTest {
@Before
public void before(){
System.out.println("Start the test!");
}
@After
public void after(){
System.out.println("End test");
}
/*
The test method can be operated independently (directly click the green switch on the left)
1.The method name is generally test + the name of the tested method
2.Add @ Test above the method
3.The test method has no parameters and return values
*/
@Test
public void testAdd(){
Calculator calculator=new Calculator();
int add=calculator.add(1,2);
System.out.println(add);
/*
Assert
Parameter 1: expected result parameter 2: actual result
*/
//Assert.assertEquals(3,add);
}
@Test
public void testDiv(){
Calculator calculator=new Calculator();
int div=calculator.div(2,0);
System.out.println(div);
}
}
Output:
Start the test! 3 End test
II Rely on conflict mediation
1. Shortest path first principle
Causes of dependency conflicts
-
Dependency delivery
Suppose your project depends on
jar
package
A
，
jar
package
A
Again dependent
jar
package
B
. When adding
jar
package
A
When, Maven
Will put
jar
package
B
Also automatically added to the project. For example, we just added
junit
Dependence,
junit
Again dependent
hamcrest
, so
Maven
Will
junit
and
hamcrest
all
Join the project.
At this time, the problem of dependency conflict may arise, such as dependency
A
Will introduce dependencies
C
, dependent
B also introduces dependencies
C
. Without mediation, two dependencies are introduced
C (and these two depend on different versions of C)
, then
Maven
How to solve the problem of dependency conflict?
Rely on conflict mediation
We take
Spring
Take dependency as an example,
spring-webmvc
rely on
spring-aop
，
spring-context
Also dependent
spring-aop
, if two versions are introduced at the same time, which version will be introduced
spring-aop
And?
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.2.12.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.2.4.RELEASE</version> </dependency>
Maven
The first principle for mediating dependency conflicts is the shortest path first principle:
That is, the version with the shortest path in the project dependency tree will be used. For example, suppose there are several
jar
The dependencies between packages are:
A
-
>B
-
>C
-
>D(2.0)
and
E
-
>F
-
>D(1.0)
, if at the same time
introduce
A
and
E
, then
D(1.0)
Will be used because
E
reach
D
The path is shorter.
The dependent paths can be viewed as follows:
The path from spring webmvc to spring AOP is as follows:
The dependency diagram for the above configuration code is as follows:
spring-webmvc
reach
spring-aop
The path of the is as follows:
The path from spring context to spring AOP is as follows:
As you can see,
spring-webmvc
reach
spring-aop
The path of is:
spring
-
webmvc
->
spring
-
context
->
spring
-
aop
and
spring-context
reach
spring-aop
The path of is:
spring
-
context
->
spring
-
aop
spring-context
reach
spring-aop
The path is shorter, so
spring-aop
Will follow the spring context
Version introduction.
2. Principle of first declaration
The shortest path first principle cannot solve all problems, such as such dependencies:
A–>B–>C(1.0)
and
D–>E–>C(2.0)
, while introducing
A
and
D
After that,
C(1.0)
and
C(2.0)
Dependent path
The length is
2
. At this point, the first principle will not solve the problem
Maven
The second principle for mediating dependency conflicts is the first declaration principle:
On the premise that the length of dependent paths is equal
POM
The order of dependency declarations in the(
That is, the configuration code on the
)Will be parsed and used. For example, in the above case,
spring-webmvc
and
spring
-context
reach
spring-core
All paths are
1
. Who declared above,
spring-core
meeting
According to whose version.
3. Exclude dependencies and lock versions
If you don't want to use
Maven
The default conflict mediation method. There are two ways to manually mediate conflicts.
Exclude dependencies
For example, in the above cases, I think
spring-webmvc
of
spring-aop
Package, then, can
spring-context
Exclude import when importing
spring-aop
Package, so that
use
spring-webmvc
of
spring-aop
Package, written as follows:
Locked version
stay
Maven
Is a
jar
After the package is configured to lock the version, the dependent declaration order and dependent path are not considered, and the locked version shall prevail. This method is developed in enterprises
Commonly used in. The following can be configured directly
spring-aop
Locked version.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>