Preface Errata Although we have taken every care to ensure the accuracy of our content,mistakes do happen.If you find a mistake in one of our books-maybe a mistake in the text or eoiemasiamapTrtaooo rs from frustration and h toy vis and will be of existing errata,under the Errata section of that title.Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support. Piracy T3ceYepohlomawggm6ma8peesar出 the protection of our copyright and licenses very seriously.If you we car inaReaerhepnpotentngourauhasandouabl时yotngo Questions You can contact us at guestion cktpub.com if you are having a problem with any aspect of the book,and we will do our best to address it. 【61
Preface [ 6 ] Errata Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub. com/support, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support. Piracy Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at copyright@packtpub.com with a link to the suspected pirated material. We appreciate your help in protecting our authors, and our ability to bring you valuable content. Questions You can contact us at questions@packtpub.com if you are having a problem with any aspect of the book, and we will do our best to address it
Getting Started with Testing We will avoid introductions to Android and the Open Handset Alliance as they are covere d in many book Brief history Initially,when Android was introduced by the end of 2007,there was very little support for testing on the platform,and for some of us very accustomed to using testing as a component in na even Ie ocumented. ofrngnlbrary and tools,I dicovered hil smthosro nttp:// .google.com/p/anarold-pos moved to p:/code.google.com/p/aut ow renamed on Android.so I decided to ext nd
Getting Started with Testing This chapter introduces the different types of testing and their applicability to software development projects in general and to Android in particular. We will avoid introductions to Android and the Open Handset Alliance (http://www.openhandsetalliance.com) as they are covered in many books already and I am inclined to believe that if you are reading a book covering this more advanced topic you will have started with Android development before. However, we will be reviewing the main concepts behind testing and the techniques, frameworks, and tools available to deploy your testing strategy on Android. Brief history Initially, when Android was introduced by the end of 2007, there was very little support for testing on the platform, and for some of us very accustomed to using testing as a component intimately coupled with the development process, it was time to start developing some frameworks and tools to permit this approach. By that time Android had some rudimentary support for unit testing using JUnit (http://www.JUnit.org), but it was not fully supported and even less documented. In the process of writing my own library and tools, I discovered Phil Smith's Positron (originally at http://code.google.com/p/android-positron and now renamed and moved to http://code.google.com/p/autoandroid), an Open Source library and a very suitable alternative to support testing on Android, so I decided to extend his excellent work and bring some new and missing pieces to the table
Getting Started with Testing Some aspects of test automation were not included and I started a complementary project to fill that gap,it was consequently named Electron.And altho ugh positror e anti-parti t theid Later on, nt Challenge(ADC1) in early 20 rks bad a rather goo e ca sted in of testin my personal blog(htp:///sec/) By that time Unit Tests could be run on Eclipse.However,testing was not done on the real target but on a JVM on the local development computer. n code through the tmed nthssfor you bfor of the ppo mentation imple mentation is described to the system through an AndroidManifest.xml file During those early stages in the Android developm some my ble ll let you be droid e manne estingbu Software bugs It doesn't matter how hard you try and how much time you invest in design and even how careful you are when programming,mistakes are inevitable and bugs will appear. Bugs and software development are intimately related.However,the term bugs to dec ed.N in ha ardware engineering many ing the s arvar ving the tion of the It has been just so in all of my inventions.The first step is an intuition,and comes witha burst,then difficulties arise-this thing gives out and lit islthe that'Bugs'-as such little faults and difficulties are called-show themselves and months of intense watching,study and labor are requisite before commercial success or failure is certainly reached." [81
Getting Started with Testing [ 8 ] Some aspects of test automation were not included and I started a complementary project to fill that gap, it was consequently named Electron. And although positron is the anti-particle of the electron, and they annihilate if they collide, take for granted that that was not the idea, but more the conservation of energy and the generation of some visible light and waves. Later on, Electron entered the first Android Development Challenge (ADC1) in early 2008 and though it obtained a rather good score in some categories, frameworks had no place in that competition. Should you be interested in the origin of testing on Android, please find some articles and videos that were published in my personal blog (http://dtmilano.blogspot.com/search/label/electron). By that time Unit Tests could be run on Eclipse. However, testing was not done on the real target but on a JVM on the local development computer. Google also provided application instrumentation code through the Instrumentation class. When running an application with instrumentation turned on, this class is instantiated for you before any of the application code, allowing you to monitor all of the interaction the system has with the application. An Instrumentation implementation is described to the system through an AndroidManifest.xml file. During those early stages in the Android development evolution, I started writing some articles in my blog filling the gaps on testing. This book is the evolution and completion of that work in an orderly and understandable manner to paradoxically let you be bitten by the Android testing bug. Software bugs It doesn't matter how hard you try and how much time you invest in design and even how careful you are when programming, mistakes are inevitable and bugs will appear. Bugs and software development are intimately related. However, the term bugs to describe flaws, mistakes, or errors has been used in hardware engineering many decades before even computers were invented. Notwithstanding the story about the term 'bug' coined by Mark II operators at Harvard University, Thomas Edison wrote this in 1878 in a letter to Puskás Tivadar showing the early adoption of the term: "It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs'—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached
Chapter1 How bugs severely affect your projects Bugs affect many aspects of your software devele oment proiect and it is clearly understood that the sooner in the process you find and squash them,the better It doesn't matter if you are developi g a simple application to publish on the Android Market,re-branding the Android experience for an operator,or creating a customized version of Android for a device manufacturer,bugs will delay your shipment and will cost you money. From all of the software development methodologies and techniques,Test Driven Development,an agile e component of the software development process,is likely th rces you to t opment process and thus it rly appreciated in Furthermore theopmn amthis technique versus one tha war rit de n the develo nt for the moile industr you will have reas ns to believe that with ll the rush this stage never occurs It'sfunny because,usually,this rush is to solve problems that could have been avoided. In a study conducted by the National Institute of Standards and Technology(USA) in 2002,it was reported that software bugs cost the economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed. But please,don't misunderstand this message.There are no silver bullets in 产 Why,what,how,and when to test You should understand that early bug detection saves a huge amount of project resources and reduces software maintenance costs.This is the best known reason to write software tests for your development project.Increased productivity will soon be evident. Additionally,writing the tests will give you a deeper understanding of the 【9]
Chapter 1 [ 9 ] How bugs severely affect your projects Bugs affect many aspects of your software development project and it is clearly understood that the sooner in the process you find and squash them, the better. It doesn't matter if you are developing a simple application to publish on the Android Market, re-branding the Android experience for an operator, or creating a customized version of Android for a device manufacturer, bugs will delay your shipment and will cost you money. From all of the software development methodologies and techniques, Test Driven Development, an agile component of the software development process, is likely the one that forces you to face your bugs earlier in the development process and thus it is also likely that you will solve more problems up front. Furthermore, the increase in productivity can be clearly appreciated in a project where a software development team uses this technique versus one that is, in the best of cases, writing tests at the end of the development cycle. If you have been involved in software development for the mobile industry, you will have reasons to believe that with all the rush this stage never occurs. It's funny because, usually, this rush is to solve problems that could have been avoided. In a study conducted by the National Institute of Standards and Technology (USA) in 2002, it was reported that software bugs cost the economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed. But please, don't misunderstand this message. There are no silver bullets in software development and what will lead you to an increase in productivity and manageability of your project is discipline in applying these methodologies and techniques to stay in control. Why, what, how, and when to test You should understand that early bug detection saves a huge amount of project resources and reduces software maintenance costs. This is the best known reason to write software tests for your development project. Increased productivity will soon be evident. Additionally, writing the tests will give you a deeper understanding of the requirements and the problem to be solved. You will not be able to write tests for a piece of software you don't understand
Getting Started with Testing This is also the reason behind the approach of writing tests to clearly understand legacy or third party code and having the ability to confidently change or update it. The more the code covered by your tests,the higher would be your expectations of discovering the hidden bugs. If during this coverage analysis you find that some areas of your code are not exercised,additional tests should be added to cover this code as well. This technique requires a special instrumented Android build to collect probe data and must be disabled for any release code because the impact on performance could severely affect application behavior. To fill this gap,enter EMMA(http://emma.sourceforge.net/),an open-source toolkit for measuring and reporting Java code coverage,that can offline instrument classes for coverage.It supports various coverage types: ·class method 。line ·basic block be btained in n diffe rmats.EMMA is ted on of Android. e of EMMA on Android to guide us to full test coverage of our ing the ternative Testing Tactics ed,pro vid the 【101
Getting Started with Testing [ 10 ] This is also the reason behind the approach of writing tests to clearly understand legacy or third party code and having the ability to confidently change or update it. The more the code covered by your tests, the higher would be your expectations of discovering the hidden bugs. If during this coverage analysis you find that some areas of your code are not exercised, additional tests should be added to cover this code as well. This technique requires a special instrumented Android build to collect probe data and must be disabled for any release code because the impact on performance could severely affect application behavior. To fill this gap, enter EMMA (http://emma.sourceforge.net/), an open-source toolkit for measuring and reporting Java code coverage, that can offline instrument classes for coverage. It supports various coverage types: • class • method • line • basic block Coverage reports can also be obtained in different output formats. EMMA is supported to some degree by the Android framework and it is possible to build an EMMA instrumented version of Android. We will be analyzing the use of EMMA on Android to guide us to full test coverage of our code in Chapter 10, Alternative Testing Tactics. This screenshot shows how an EMMA code coverage report is displayed in the Eclipse editor, showing green lines where the code has been tested, provided the corresponding plugin is installed