Android test-driven development practices

In Android Application Development, it is believed that few people insist on the complete outline design and detailed design by the designer, and then hand it over to the programmer for coding. Generally, the code development starts with a general framework. In this case, the development speed can be greatly improved, but the final code quality is inevitably reduced. How can we keep the development speed while ensuring the development quality? I believe that test-driven development is a feasible development methodology.

Test-driven development first designs test cases to refine the process from user needs to method interfaces. The process of imagining these test cases is to think about the system from the user's perspective, in the traditional method, the designers usually think about the problem from the technical perspective. Compared with the two, it is obvious that test-driven development is more helpful to develop products that meet user needs, develop high-availability code at the same time.

Test-driven development first writes the test, which ensures that the method user needs are fully taken into account and makes the method more reasonable. Next we will conduct code development and pass the test case as short as possible. In this process, we will temporarily forget the OO and design patterns. After passing the test case, let's look back at our code implementation, remove inter-class dependencies, and use the appropriate design pattern, which is much better than imagined at the beginning. By repeating the above process, you can naturally get code and systems of higher quality.

However, in the Android system, testing-driven development adds extra difficulty. How to perform unit tests on Activity, Provider, Service, Broadcaster, and so on is a problem that must be solved, next we will look at how to solve this series of problems with the development of an actual system.

For test-driven development, the first thing to do is to build a truly runable skeleton system, which is no exception for testing-driven development in Android.

First, create an Android project. Here, taking mhcs as an example, use the Eclipse Wizard to create this project. Assume that this project is used for the first time by the user, three presentation pages need to be displayed, and the user starts to use the normal function only after one line is crossed. Next, we will take this function as an example to describe in detail how to perform test-driven development in Android.

First, prepare three introduction images and put them in the res/drawable directory. We define the FlipIntroActivity class to process user's drag operations and introduce image display. Because the introduction page is displayed only when the user runs for the first time, it is necessary to save information about whether the user uses the system for the first time. We use the Application subclass AppPreferences to manage all the information required by the Application.

At this time, the functions we need to complete are clear. The introduction page is displayed when the program is running for the first time, but the introduction page is not displayed when the program is running. Whether to display the introduction page, which is managed by the AppPreferences class.

Next, create a Test project in Eclipse, select the new project type as Android Junit Test project, and select the project created above as the project to be tested.

Well, the minimum runable skeleton system has been established. Now we can enter the formal test-driven development process.

First, write the test case: Create a class AppPreferencesTest. Because the tested class AppPreferences is a subclass of the Application, the AppPreferencesTest class must inherit ApplicationTestCase.

public class AppPreferencesTest extends ApplicationTestCase<AppPreferences> {public AppPreferencesTest(Class<AppPreferences> applicationClass) {super(applicationClass);}}

First, we test AppPreferences. At the first run, we can return true. In the AppPreferencesTest class, add the following test code:

public void testFirstRunTrue() {assertTrue(prefs.isFirstRun());}private AppPreferences prefs = new AppPreferences();

As you can see, this code compiler makes an error immediately. Don't worry, test-driven development always starts from a test case that cannot be passed. Every time you try to pass a test case, make progress when passing test cases.

The following code is written first. Through this test case, we add the following code to the AppPreferences class:

public boolean isFirstRun() {return isFirstRun;}public void setFirstRun(boolean isFirstRun) {this.isFirstRun = isFirstRun;}private boolean isFirstRun = true;

However, if it is the second operation, will the system still display true? This is obviously incorrect! Right at all, this code does not implement our previous ideas, but it can pass our test cases. The principle of test-driven development is to pass test cases as quickly as possible.

All right, select AppPreferencesTest in the Test project, and then select Android Junit Test to run the system. You will see the green use case marked in the Junit view.

Next, add a piece of code to test the second running time:

public void testSecondAndMoreRun() {prefs.isFirstRun();assertFalse(prefs.isFirstRun());}

Run the above project and the test case testSecondAndMoreRun cannot pass. Next we will handle this situation and add the following code to the AppPreferences class in the production project:

public boolean isFirstRun() {boolean orgVal = isFirstRun;isFirstRun = false;return orgVal;}

Then we run the AppPreferencesTest class of the test project, and we can see the green sign that makes us feel relaxed.

Next, the first run is available, and the second run is unavailable. The Code is as follows:

Add the following to the production project class AppPreferences:

@Overridepublic void onCreate() {super.onCreate();}public void onTerminate() {super.onTerminate();}public boolean isFirstRun() {prefs = getSharedPreferences("mhcs", MODE_PRIVATE);boolean orgVal = isFirstRun;isFirstRun = false;Editor editor = prefs.edit();editor.putBoolean(PREF_IS_FIRST_RUN, false);editor.commit();return orgVal;}public void setFirstRun(boolean isFirstRun) {this.isFirstRun = isFirstRun;}public final static String PREF_IS_FIRST_RUN = "isFirstRun";private SharedPreferences prefs = null; private boolean isFirstRun = true;

Add code to the test class of the test project:

public void testFirstRunTrue() {createApplication();prefs = getApplication();Editor editor = mContext.getSharedPreferences("mhcs", 0).edit();editor.clear().commit();assertTrue(prefs.isFirstRun());}public void testSecondAndMoreRun() {createApplication();prefs = getApplication();assertFalse(prefs.isFirstRun());}

Note that in the testFirstRunTrue method, the SharedPreferences is cleared first to simulate the first running of the program after installation.

After running the test cases of the test project, you can see the green pass mark of the complete function.