Recently, I have been doing unit testing. I have packaged some testing tools and provided AAR packages for others to reference. That’s it. Let’s wrap it up and share the framework we’ve encapsulated.

Unit testing concept

Unit tests are tests written to test a unit of code. A code unit, which can be a module, a class, or a method. In OOP, a unit of code refers to a method of a class. So, unit tests are tests written to test a method of a class.

Example:

Existing classes:

public class Calculator { public int add(int num1, int num2){ return (num1 + num2); }}Copy the code

The test class:

public class CalculatorTest { Calculator calculator; @before public void setUp() throws Exception {system.out.println (" test preparation "); calculator = new Calculator(); } @test public void testAdd() {system.out.println (" testAdd()"); int sum = calculator.add(2, 3); Assert.assertEquals(5, sum); } @after public void tearDown() throws Exception {system.out.println (" end of test "); }}Copy the code

As you can see from the sample code, the test is divided into three main parts:

  1. The preparatory worksetUp()

To do some initialization work, annotate with @before.

  1. The test methodtest**()

The general naming rule is test+ the name of the method to be tested, annotated with @test. Call the method you want to test here, get the run results, and verify that the run results are as expected.

  1. The end of the testtearDown()

At the end of the test, sometimes resources need to be released, and tests can be released uniformly in this method. You need to annotate with @after.

SetUp () and tearDown() are optional, depending on the situation. In general, writing unit tests requires some testing framework, and this article introduces JUnit4. Assert.assertequals () in the sample code above is the method used in JUnit to verify the result, along with assertEquals,assertTrue, assertNotNull, and so on.

Benefits of unit testing

  1. Improving code quality

The crash rate can be reduced and bugs can be found earlier

  1. Improve code design

When you write unit tests for your code, especially with TDD, you make each class small and single-purpose, which is an important single-responsibility principle in software design. In addition, you can clearly assign responsibility to each function, rather than cramming a bunch of code into a class (such as an Activity). When you TDD, you write your code as a user, or maintainer, from the very beginning. The resulting code will naturally have a better design.

  1. Give you confidence

Having unit tests to make sure that your code is correct gives you confidence that you can write it, publish it, and refactor it with less worry.

Learning costs

* JUnit * Mockito * PowerMock * Robolectric * Espresso * UI Automator * DI *...Copy the code

Time cost

Adding unit tests to a project that doesn’t have them can take a lot of time at first. Because you need to spend time tweaking parts of the code to make them easy to test.

Unit tests can take a lot of time when you first start writing them, but they can save you time once you get used to the development pattern. Because it’s easy to write unit tests on a class or a method once you’re familiar with how to write unit tests. If you find a class difficult to test, it’s usually because the design of the class is flawed. In addition, in the process of writing unit tests, you can slowly build your own test framework, simplify some common tedious writing methods, so that writing unit tests becomes easier and faster.

In general, writing unit tests may take a little time at first, but it’s worth it in the long run, and unit tests can save time.

Technology selection

Depending on the requirements, Android UI tests and Java layer tests are included, so these are used: junit + Mockito + PowerMock + Espresso. In order to make the test report beautiful, extentReport is used to beautify the report. In addition to the built-in functionality of these test frameworks, other things are encapsulated, such as CPU usage, memory usage, and so on. After wrapping these third-party tools, users only need to introduce three AArs for testing.

In use, first copy the three AAR packages to app/libs/ directory,

Add the following code to build.gradle:

TestImplementation files ('/libs/UnitTestSDKJava - 1.0.0. Aar ') androidTestImplementation Files ('/libs/UnitTestSDKAndroid - 1.0.0. Aar ') testImplementation files ('. / libs/UnitTestSDKReport - 1.0.0. Aar ') AndroidTestImplementation files ('/libs/UnitTestSDKReport - 1.0.0. Aar ')Copy the code

Unittestsdkjava-1.0.0. aar is a Java level test that does not require launching the emulator or connecting to a real Android device, and is independent of the business code, so the dependency is introduced with testImplementation; UnitTestSDKAndroid – 1.0.0. Aar is a test of the Android UI layer, generally use androidTestImplementation introducing dependence, but if the need for asynchronous update UI test, you need to insert test related code in the business code, So that’s where we need to use implementation to introduce dependencies.

Note: When creating a project using Android Studio, some unit test dependencies are automatically introduced. To avoid dependency conflicts, remove the automatically introduced unit test dependencies.

At this point, you can write unit tests using the framework.