Android Development notes: Some suggestions for practicing TDD are explained _android

The most recent part of the TDD approach is to develop a module with little to no gain.
1. Basic principles of TDD
The core idea of TDD is to identify requirements first, quantify them in code, define requirements standards, and then encode them to achieve standards that are measured by code testing.
Then it requires, first write out the required standards, write one at a time. The encoding implementation is achieved through, and meets exactly this standard. This iteration of the 1.1 point.
There are three advantages: one is to clear the standard before we lose the theme and deviate from the direction. There are standards in the test, to ensure that the code is correct. Meet the current test only, not premature optimization and excessive design.
2. The difficulties of TDD
The difficulty is how to design this Test standard,
1 Make it small enough to be a requirement unit;
2) become the standard, that is how to detect correctness;
3 is how to simulate a real-life scene, rather than write a lot of extra tools for testing, which means that the test should be the same as the real project code, there should be no superfluous things.
The key is to analyze the mining requirements and refine the requirements. If you test some APIs like the one in the book, it's good to write, because the test code invokes the API in the same way as the real app code, and the API functions are clearly described. But the reality is not so, for example, many frameworks are difficult to test, many objects and create and control are done by the framework, you can not like control. This leads to the difficulty of writing test cases.
There is multithreading, due to the uncertainty of the thread, there are many false failures, this can be reference books, the book has methods.
3. TDD in Android
To be honest, it's impossible to exploit Android entirely in a TDD way. The reasons are as follows:
1. The main structure of applications in Android is the four components: Service,activity and provider and receiver the creation and destruction of these four things are controlled by the framework. So you can't test them as you would in the book, because there are limitations that you can't test with code.
2. Some things are callbacks to the system framework or very basic things that do not have to write testcase. such as the handling of the Click/longclick/touch event of the view, or the life cycle callback of the activity, or the optionsmenu/contextmenu.
3. The API for testing in the SDK is too weak
This leads to a lot of work and a lot of code written to test a small function, much larger than direct implementation. For example, test a pop-up dialog, if the direct implementation is easy, but if the code to test more than 3, 4 times times the workload, much more than direct implementation.
4. How do you use TDD in Android? Here are some suggestions:
1. Use of Robotium
This is a powerful tool, it is more convenient than the things in the SDK, such as Searchtext,clickmenu and other interfaces is very convenient and practical.
2. Automatic Test + Manual Test
Also follow the principle, but for test cases, there is no need to completely use the code to write, can be part of manual testing: Generally speaking, if the automatic testing more convenient implementation of the write testcase, if the manual test is very convenient manual test, this is not dead rules to see the specific situation.
For example, view events, activity events, Menu,dialog, and so on, and use cases across application interactions are best tested manually, because they are more cumbersome to test with code.
But for some involving numerical, computational, quantification, etc., it is done in code. For example, download a file, set a good path, you can use the file object directly to detect whether the download success.
3. Provider must be tested
Provider provides the API, it is very good test is easy to write, is also a project infrastructure, so must be well tested, or if there is a problem in the activity of a data, you have to determine whether there is a problem in the display or provider. Usually crud must be tested, there is the where statement, and the reverse test, the validity of the URI must be detected, and the processing of special characters, such as ' and '.
4. In addition to service and activitySomething other than that, especially if you implement a class like API, you should test it if it involves some business logic. As is the case in the book, the difficult achievement of testing depends on the decomposition, design and coupling of the business.
5. Test the interior of the class with reflection
While service and activity can be testcase in the sample, service and activity is a component unit in the actual will not be public too many interfaces, they are at the top of the call to other interfaces, and they do not, You should also not expose interfaces to others because their creation and lifecycle management are controlled by the system, and there should not be too many references to them elsewhere.
So what do you do when you're testing the service and the internal activity? For example, to test a service inside a int[] mplaylistqueue. We can't add an interface to our service in order to write case. The reflection mechanism is used to remove the instance of the member and then examine its data.
6. Some things must be tested manually, automation can not be completed
TestCase is a special context and mockobject, a maximized simulation of the real Android operation, and it's not exactly the same as when the application actually runs! And because of the permission reason, some things instrumentation can not do, such as alarm, date instrumentation is no permission to change. These must be tested manually.
There is the service and activity of the initialization and destruction, especially the destruction, no way to test, that is, for OnDestroy () inside things, it is really bad to test. First, you don't know when it's going to be called back; second, the object is destroyed when it is executed, and the reference you hold is not necessarily valid; Third, whether the member object is valid or not known. For OnDestroy can only be tested manually by means of debugging.
in short, it seems to me that the core idea of TDD is to test first, realize later. But how to test does not have the stipulation to use the code, therefore chooses the best test method according to the actual situation.