Android development: some suggestions for using TDD

The TDD method has recently been used to develop a module. The following is a summary:

1. Basic principles of TDD

The core idea of TDD is to first clarify the requirements, quantify the requirements in the form of code, clarify the requirements standards, and then implement code to achieve the standards measured by code testing.
Therefore, it requires that you first write the criteria and write only one at a time. The code is implemented and meets this standard. In this way, the 1.1 point iteration is performed.
There are three advantages: one is to clarify standards first, so that we will not lose the topic and deviate from the direction. There are standards in the detection to ensure that the Code is correct. It only meets the current test and does not lead to premature optimization or over-design.

2. TDD difficulties

The difficulty lies in how to design this test standard,

1) make it small enough to be a demand unit;

2) become a standard, that is, how to detect correctness;

3) it is how to simulate the actual running scenario to the maximum extent, instead of writing many additional tools for testing. That is to say, testing should be the same as real project code and there should be no extra things.

The key lies in analyzing and mining requirements and refining requirements. It would be nice to test some APIs like the examples in the book, because the test code calls the API in the same way as the real app code, and the API functions will be clearly described. However, this is not the case in reality. For example, many frameworks are difficult to test, and many objects and creation and control tasks are implemented by the framework, and you cannot perform similar control. This makes it difficult to write test cases.
There is also multithreading. Due to the uncertainty brought about by threads, there are many pseudo failures. This can be referenced in the book as a reference.

3. TDD in Android

To be honest, it is impossible to use TDD in Android development. The reason is as follows:

1. The main structure of applications in Android is four components: Service, activity, provider, and consumer er. the creation and destruction of these four components are controlled by the framework. Therefore, you cannot test them like the examples in the book, because some restrictions make it impossible to test them using code.

2. Some are system framework callbacks or basic things do not need to be written into testcase. For example, the processing of view click/longclick/touch events, activity lifecycle callback, or optionsmenu/contextmenu.

3. the API used for testing in the SDK is too weak.

This leads to a lot of work and code to test a small function, far greater than direct implementation. For example, to test a pop-up dialog, it is easy to implement it directly; but if you use code to test it, it requires 3 or 4 times more work, much greater than direct implementation.

4. How should TDD be used well in Android? The following are some suggestions:

1. Use robotium

This is a powerful tool. It is much more convenient than the SDK, such as searchtext and clickmenu.

2. Automatic Test + manual test

We also need to follow the principles, but for test cases, there is no need to use code to write them completely. Some manual tests can be performed. Generally, If Automatic tests are easier to implement, we should write testcase, if the manual test is convenient, you can perform the manual test. If there are no dead rules, you should check the specific situation.

For example, it is best to manually test view events, Activity events, activity menus, dialog and other interaction-related things, and cross-application interaction cases, this is because it is more troublesome to use code for testing.

However, code is used for values, computation, and quantification. For example, after downloading an object and setting the path, you can directly use the file object to check whether the object has been downloaded successfully.

3. provider must be tested

The provider provides an API, which is very good for testing and easy to write. It is also the basic facility of a project. Therefore, you must test it well. Otherwise, if a data entry in the activity has a problem, you must determine whether a problem is displayed or a problem occurs in the provider. Generally, crud must be tested, and the where statement and reverse test must be used to check the validity of the URI, and the processing of special characters such as 'and ".

4. In addition to services and activities, especially self-implemented API-like classes, test some business logic. This is similar to the example in the book. The difficulty of testing depends on the business decomposition, design, and coupling. 5. Use reflection to test the internal class

Although the service and activity can get its instances in testcase, the service and activity are a component unit that does not actually make too many public interfaces, they call other interfaces at the top, but they do not, and should not be exposed to others, because their creation and lifecycle management are controlled by the system, there should not be too many references to them elsewhere.
So what should I do when I want to test the service and activity? For example, you want to test an int [] mplaylistqueue in a service. We cannot add an interface to the service to write the case! In this case, the reflection mechanism is used to retrieve the member instance and check its data.

6. Some things must be manually tested, and automation cannot be completed.

Testcase has special context and mockobject. It is a maximum simulation of real android running. It is not exactly the same as when the application is actually running! In addition, due to permission, Some instrumentation tasks cannot be performed, such as alarm and date. These must be manually tested.

There is also the initialization and destruction of services and activities, especially destruction, which cannot be tested. That is to say, it is really difficult to test what is in ondestroy. First, you don't know when it will be called back. Second, when it is executed, the object will be destroyed, and your reference may not be valid. Third, it is unknown whether all member objects are valid. Ondestroy can only be manually tested through debugging.

In short, in my opinion, the core idea of TDD is to test first, and then implement later. However, there is no rule on how to test the code, so select the best test method based on the actual situation.