Maven Engineering Testing & relying on conflict mediation

catalogue

I Maven engineering test

1. Test overview

2.Junit usage steps

3.Junit result judgment

4.@Before,@After

II Rely on conflict mediation

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>

 

Tags: JavaEE Maven

Posted by woza_uk on Sun, 15 May 2022 04:58:16 +0300