Chapter1 贤器： erature:2e belev rere" Unfortunately,the plugin doesn't support Android tests yet,so right now you can hrough Hyour JUnit tests.An Android coverage analysis report is only available onry us Tests should be automate ndyou me or all of th ry time e you con sed of tests ibl of the ent process anc Is very opt Cont What to test Strictly speaking you should test every statement in your code but this also depends on different criteria and can be reduced to test the path of execution or just some methods.Usually there is no need to test something that can't be broken,for example it usually makes no se won't be testing th have already 【111
Chapter 1 [ 11 ] Unfortunately, the plugin doesn't support Android tests yet, so right now you can only use it for your JUnit tests. An Android coverage analysis report is only available through HTML. Tests should be automated, and you should run some or all of them every time you introduce a change or addition to your code, in order to ensure that all the previous conditions are still met and that the new code still satisfies the tests as expected. This leads us to the introduction of Continuous Integration, which will be discussed in detail in Chapter 8, Continuous Integration. This relies on the automation of tests and building processes. If you don't use automated testing, it is practically impossible to adopt Continuous Integration as part of the development process and it is very difficult to ensure that changes do not break existing code. What to test Strictly speaking you should test every statement in your code but this also depends on different criteria and can be reduced to test the path of execution or just some methods. Usually there is no need to test something that can't be broken, for example it usually makes no sense to test getters and setters as you probably won't be testing the Java compiler on your own code and the compiler would have already performed its own tests
Getting Started with Testing In addition to the functional areas you should test,there are some specific areas of Android applications that you should consider.We will be looking at these in the following sections. Activity lifecycle events You should test that your activities handle lifecycle events correctly. If your activity should save its state during onpause()or onDestroy()events and later restore it in oncreate (Bundle savedInstancestate),you should be able to reproduce and test these conditions and verify that the state was correctly saved and restored. Configuration-changed events should also be tested as some of these events cause the current Activity to be recreated,and you should test for correct handling of the ous state.Connguration and thatbyrotation events,so you should test your application's n by rotation events,so you sho situation Database and filesystem operations Database and filesystem operations should be tested to ensure that they are handled n level,at To test th e components in isolation,Android provides some mock objects in the android.test.mock package Physical characteristics of the device livering your application you s Among other characteristics of the devices,you may find that you should test Network capabilities ·Screendensities 。Screen resolutions Screen sizes Availability of sensors 【12]
Getting Started with Testing [ 12 ] In addition to the functional areas you should test, there are some specific areas of Android applications that you should consider. We will be looking at these in the following sections. Activity lifecycle events You should test that your activities handle lifecycle events correctly. If your activity should save its state during onPause() or onDestroy() events and later restore it in onCreate(Bundle savedInstanceState), you should be able to reproduce and test these conditions and verify that the state was correctly saved and restored. Configuration-changed events should also be tested as some of these events cause the current Activity to be recreated, and you should test for correct handling of the event and that the newly created Activity preserves the previous state. Configuration changes are triggered even by rotation events, so you should test your application's ability to handle these situations. Database and filesystem operations Database and filesystem operations should be tested to ensure that they are handled correctly. These operations should be tested in isolation at the lower system level, at a higher level through ContentProviders, and from the application itself. To test these components in isolation, Android provides some mock objects in the android.test.mock package. Physical characteristics of the device Well before delivering your application you should be sure that all of the different devices it can be run on are supported or at the least you should detect the situation and take appropriate measures. Among other characteristics of the devices, you may find that you should test: • Network capabilities • Screen densities • Screen resolutions • Screen sizes • Availability of sensors
Chapter 1 Keyboard and other input devices ·GPS ·External storage In this re rtant role hecause it is ssible to have access to all p anmacttrohimofetosbe combinations of features but you can configure AVD for almost every situation. However,as was mentioned before,save your final testing for actual devices where real users will run the application to understand its behavior. Types of tests ed Ho cess,depen the develot ent effort.even before the full set of requirem ents have been defined and the coding process has been started. There are several types of test available depending on the obiect being tested. Regardless of its type,a test should verify a condition and return the result of this evaluation as a single Boolean value indicating success or failure. Unit tests tests are software tests written by programmers for programmers a they shou er test and be objects are placed o epe xample.if your test deletes some data from a database obon'ant he data to be actually deleted and not found the next time the test is run. JUnit is the de-facto standard for unit tests on Android.It's a sir framework for automating unit testing originally written by Erich Gamma and Kent Beck. Android(up to Android 2.3 Gingerbread)uses JUnit 3.This version doesn't use annotations and uses introspection to detect the tests. A typical JUnit test would look something like this(the actual tests are highlighted): / Android Applicaion Testing Quide package com.example.aatg.test 【13]
Chapter 1 [ 13 ] • Keyboard and other input devices • GPS • External storage In this respect Android Virtual Devices play an important role because it is practically impossible to have access to all possible devices with all of the possible combinations of features but you can configure AVD for almost every situation. However, as was mentioned before, save your final testing for actual devices where real users will run the application to understand its behavior. Types of tests Testing can be implemented at any time in the development process, depending on the method employed. However, we will be promoting testing at an early stage of the development effort, even before the full set of requirements have been defined and the coding process has been started. There are several types of test available depending on the object being tested. Regardless of its type, a test should verify a condition and return the result of this evaluation as a single Boolean value indicating success or failure. Unit tests Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way. That's why unit tests and mock objects are usually placed together. You use mock objects to isolate the unit from its dependencies, to monitor interactions, and also to be able to repeat the test any number of times. For example, if your test deletes some data from a database you probably don't want the data to be actually deleted and not found the next time the test is run. JUnit is the de-facto standard for unit tests on Android. It's a simple open source framework for automating unit testing, originally written by Erich Gamma and Kent Beck. Android (up to Android 2.3 Gingerbread) uses JUnit 3. This version doesn't use annotations and uses introspection to detect the tests. A typical JUnit test would look something like this (the actual tests are highlighted): /** * Android Application Testing Guide */ package com.example.aatg.test;
Getting Started with Testing import JUnit.framework.Testcase; /* author diego public class MyUnitTests extends Testcase private int mFixture; /生 param name test name public MyUnitTests(string name){ super(name); /(aon-Javadoc) JUnit.frame work.Testcase#setUp() protected void setUp()throws Exception 广oeomit:aneokieatcaetearno /(non-Javadoc) ublc void p()( Test method public void testsomething(){ fail("Not implemented yet") Downloading the example code You can dov purchased this upport and register rectly to you 【141
Getting Started with Testing [ 14 ] import JUnit.framework.TestCase; /** * @author diego */ public class MyUnitTests extends TestCase { private int mFixture; /** * @param name test name */ public MyUnitTests(String name) { super(name); } /* (non-Javadoc) * @see JUnit.framework.TestCase#setUp() */ protected void setUp() throws Exception { super.setUp(); mFixture = 1234; } /* (non-Javadoc) * @see JUnit.framework.TestCase#tearDown() */ protected void tearDown() throws Exception { super.tearDown(); } /** * Preconditions */ public void testPreconditions() { } /** * Test method */ public void testSomething() { fail("Not implemented yet"); } } Downloading the example code You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub. com/support and register to have the files e-mailed directly to you
Chapter1 The following sections explain in detail the components that build up our test case The test fixture A test ftur i the el known state defined as a bnlin on the tests and is and thus plays a fun the design of the variables and,following Android ntions.they However.it can also contain external data,as specific entries in a database or files present in the filesystem. The setUp()method This method is called to initialize the fixture setup every test. The tearDown()method This method is called to finalize the fixture Overriding it you can release resources used by the initialization or tests.Again, this method is invoked after every test For example,you can release a database or a network connection here. JUnit is designed in such a way that the entire tree of test instances is built in one pass,and then the tests are executed in a second pass.Therefore,the test runner holds strong references to all Test instances for the duration of the test execution. This means that for very large and very I ng te t runs wI many none larly tests ma ndrd and whe re test run tests needed to run the application plus its tests exceeding the device limits. Therefore,if you allocate external or limited resou ces in a test,such as se Content Providers.you are re esponsible for freeing those resources.Explicitly setting an object to null in the tearDown (method,for example,allows it to be garbage collected before the end of the entire test run. 【15] www.allitebooks.com
Chapter 1 [ 15 ] The following sections explain in detail the components that build up our test case. The test fixture A test fixture is the well known state defined as a baseline to run the tests and is shared by all the test cases, and thus plays a fundamental role in the design of the tests. Generally it is implemented as a set of member variables and, following Android conventions, they will have names starting with m, for example mActivity. However, it can also contain external data, as specific entries in a database or files present in the filesystem. The setUp() method This method is called to initialize the fixture. Overriding it you have the opportunity to create objects and initialize fields that will be used by tests. It's worth noting that this setup occurs before every test. The tearDown() method This method is called to finalize the fixture. Overriding it you can release resources used by the initialization or tests. Again, this method is invoked after every test. For example, you can release a database or a network connection here. JUnit is designed in such a way that the entire tree of test instances is built in one pass, and then the tests are executed in a second pass. Therefore, the test runner holds strong references to all Test instances for the duration of the test execution. This means that for very large and very long test runs with many Test instances, none of the tests may be garbage collected until the end of the entire test run. This is particularly important in Android and when testing on limited devices as some tests may fail not because of an intrinsic problem but because of the amount of memory needed to run the application plus its tests exceeding the device limits. Therefore, if you allocate external or limited resources in a test, such as Services or ContentProviders, you are responsible for freeing those resources. Explicitly setting an object to null in the tearDown() method, for example, allows it to be garbage collected before the end of the entire test run. www.allitebooks.com