A Study on Open-Source Android Applications
A Study on Open-Source Android Applications
Android applications do not seem to be tested as thor-oughly as desktop ones. In particular, graphical user interface(GUI) testing appears generally limited. Like web-based appli-cations, mobile apps suffer from GUI test fragility, i.e., GUI testclasses failing or needing updates due to even minor modifica-tions in the GUI or in the application under test. The objective ofour study is to estimate the adoption of GUI testing frameworksamong Android open-source applications, the quantity of modifi-cations needed to keep test classes up to date, and their amount dueto GUI test fragility. We introduce a set of 21 metrics to measurethe adoption of testing tools and the evolution of test classes andtest methods, and to estimate the fragility of test suites. We com-puted our metrics for six GUI testing frameworks, none of whichachieved a significant adoption among Android projects hosted onGitHub. When present, GUI test methods associated with the con-sidered tools are modified often, and a relevant portion (70% onaverage) of those modifications is induced by GUI-related fragili-ties. On average, for the projects considered, more than 7% of thetotal modified lines of code between consecutive releases belong totest classes developed with the analyzed testing frameworks. Themeasured percentage was higher on average than the one requiredby other generic test code, based on the JUnit testing framework.Fragility of GUI tests constitutes a relevant concern, probably anobstacle for developers to adopt test automation. This first evalua-tion of the fragility of Android scripted GUI testing can constitutea benchmark for developers and testers leveraging the analyzedtest tools and the basis for the definition of a taxonomy of fragilitycauses and guidelines to mitigate the issue.CodeShoppy
A definition of mobile appsis given by Mucciniet al.[7] asmobile software (i.e., applications that run on electronic devicesthat may move) that in addition to the user’s input, they are alsocontext aware, i.e., they adapt and react to the context in whichthey are run (for instance, performing sensing of the physicalenvironment and context-triggered actions).A first classification of mobile apps may be made betweennative,web-based,andhybridapplications. As explained byKirubakaran and Karthikeyani [9], native apps are the ones de-signed to be run on a particular mobile platform, following itsdesign patterns and guidelines. Web-based apps are pretty sim-ilar in their nature to typical web applications and are based onwebsites that are engineered to be loaded by a browser on a mo-bile device. Hybrid apps use native code for specific platformsto provide a client to the user and to access functionalities of thedevice they run on, but still their core logic is written as a webapplication and is loaded dynamically at runtime.The Android development platform, as described byAmalfitanoet al.[10], is an infrastructure composed of fourlayers: the final applications, at the top of the stack; the AndroidApplication Framework, providing the components with whichthe apps are built; the Static Library and the Android Runtime(including the Dalvik Virtual Machine, on which the apps areexecuted); and the Linux kernel, in charge of abstracting theunderlying hardware.The Android application framework provides four basic com-ponents, which are the elements with which applications areconstructed.Activitiesbuild the various components of theGUIs, defining their elements and handling the responses thatneed to be triggered by different classes of user inputs (e.g.,tactile or vocal).Servicesmanage long-running background op-eration, which need no interaction by the user, like the man-agement of network connections.Broadcast receiverslisten toevents that are launched by the Android system (e.g., incomingcalls or low battery signal) and manage the way the applicationresponds to them.Content providersmanage the data stored bythe application and allow us to share data with other apps andaccess external data. Each component is characterized by a spe-cific life cycle, and each transition between its states should beproperly tested in order to guarantee that no crashes or unex-pected behaviors happen. Since the interactions with the GUIand the graphic elements are entirely managed by activities,GUI testing for Android apps is strictly tied to activity testing.
In this paper, we aimed at taking a snapshot of the usageof automated GUI testing frameworks among Android open-source projects. We quantified the use of a set of six toolsthat can be used for GUI testing and that are cited in avail-able literature—Espresso, UIAutomator, Selendroid, Robotium,obolectric, and Appium—in the projects hosted by the Git Hub portal.We found that the level of adoption of the considered GUItesting frameworks among Android projects hosted on GitHubis very scarce, even for those tools that are part of the Androidinstrumentation framework. The whole adoption of all the sixtesting tools considered is about 8% of all projects that have arelease history. This value can be compared to the 20% adoptionof the JUnit framework. For what concerns individual projects,on average, when present, the testing code related to the sixselected framework represents 13% of all the production code.This result is slightly lower than those obtained by Kochharet al.[5] regarding the projects hosted on the F-Droid repository,where only 14% apps contained executable test classes.
Android applications do not seem to be tested as thor-oughly as desktop ones. In particular, graphical user interface(GUI) testing appears generally limited. Like web-based appli-cations, mobile apps suffer from GUI test fragility, i.e., GUI testclasses failing or needing updates due to even minor modifica-tions in the GUI or in the application under test. The objective ofour study is to estimate the adoption of GUI testing frameworksamong Android open-source applications, the quantity of modifi-cations needed to keep test classes up to date, and their amount dueto GUI test fragility. We introduce a set of 21 metrics to measurethe adoption of testing tools and the evolution of test classes andtest methods, and to estimate the fragility of test suites. We com-puted our metrics for six GUI testing frameworks, none of whichachieved a significant adoption among Android projects hosted onGitHub. When present, GUI test methods associated with the con-sidered tools are modified often, and a relevant portion (70% onaverage) of those modifications is induced by GUI-related fragili-ties. On average, for the projects considered, more than 7% of thetotal modified lines of code between consecutive releases belong totest classes developed with the analyzed testing frameworks. Themeasured percentage was higher on average than the one requiredby other generic test code, based on the JUnit testing framework.Fragility of GUI tests constitutes a relevant concern, probably anobstacle for developers to adopt test automation. This first evalua-tion of the fragility of Android scripted GUI testing can constitutea benchmark for developers and testers leveraging the analyzedtest tools and the basis for the definition of a taxonomy of fragilitycauses and guidelines to mitigate the issue.CodeShoppy
A definition of mobile appsis given by Mucciniet al.[7] asmobile software (i.e., applications that run on electronic devicesthat may move) that in addition to the user’s input, they are alsocontext aware, i.e., they adapt and react to the context in whichthey are run (for instance, performing sensing of the physicalenvironment and context-triggered actions).A first classification of mobile apps may be made betweennative,web-based,andhybridapplications. As explained byKirubakaran and Karthikeyani [9], native apps are the ones de-signed to be run on a particular mobile platform, following itsdesign patterns and guidelines. Web-based apps are pretty sim-ilar in their nature to typical web applications and are based onwebsites that are engineered to be loaded by a browser on a mo-bile device. Hybrid apps use native code for specific platformsto provide a client to the user and to access functionalities of thedevice they run on, but still their core logic is written as a webapplication and is loaded dynamically at runtime.The Android development platform, as described byAmalfitanoet al.[10], is an infrastructure composed of fourlayers: the final applications, at the top of the stack; the AndroidApplication Framework, providing the components with whichthe apps are built; the Static Library and the Android Runtime(including the Dalvik Virtual Machine, on which the apps areexecuted); and the Linux kernel, in charge of abstracting theunderlying hardware.The Android application framework provides four basic com-ponents, which are the elements with which applications areconstructed.Activitiesbuild the various components of theGUIs, defining their elements and handling the responses thatneed to be triggered by different classes of user inputs (e.g.,tactile or vocal).Servicesmanage long-running background op-eration, which need no interaction by the user, like the man-agement of network connections.Broadcast receiverslisten toevents that are launched by the Android system (e.g., incomingcalls or low battery signal) and manage the way the applicationresponds to them.Content providersmanage the data stored bythe application and allow us to share data with other apps andaccess external data. Each component is characterized by a spe-cific life cycle, and each transition between its states should beproperly tested in order to guarantee that no crashes or unex-pected behaviors happen. Since the interactions with the GUIand the graphic elements are entirely managed by activities,GUI testing for Android apps is strictly tied to activity testing.
In this paper, we aimed at taking a snapshot of the usageof automated GUI testing frameworks among Android open-source projects. We quantified the use of a set of six toolsthat can be used for GUI testing and that are cited in avail-able literature—Espresso, UIAutomator, Selendroid, Robotium,obolectric, and Appium—in the projects hosted by the Git Hub portal.We found that the level of adoption of the considered GUItesting frameworks among Android projects hosted on GitHubis very scarce, even for those tools that are part of the Androidinstrumentation framework. The whole adoption of all the sixtesting tools considered is about 8% of all projects that have arelease history. This value can be compared to the 20% adoptionof the JUnit framework. For what concerns individual projects,on average, when present, the testing code related to the sixselected framework represents 13% of all the production code.This result is slightly lower than those obtained by Kochharet al.[5] regarding the projects hosted on the F-Droid repository,where only 14% apps contained executable test classes.
https://codeshoppy.com/php-projects-titles-topics.html
.png)
Comments
Post a Comment