Chapter1 Also check Fit,http://fit.c2.com and Slim(Simple List Invocation fitnesse.org/FitNesse.UserGuide.sliM,as 从 TemperatureConverterCelslusToFahrenheitFixture celsiusfahrenheit? 0.0 32.0-=32 100.0212.0 Suite 1.030.2 Edit 100.0148.0 Properties 32.089.6 Refactor 40.040.0 Where Used 273.0 【459.40000000000003 ]expected【-=459.④ 273 【459.40000000000003]expected【-=-459.4] Search 273 [-459.400000000000031 expected【=459 Files 273 【-459.40000000000003】expected[-=-459.40000000000003] Versions 273 -459.40000000000003 Recent Changes 273 【459.40000000000003)expected【459.41<-<-459.40 -274.0 Invalid temperature:-274.00C below absolute zero Lately,a new trend named Behavior Driven Development has gained some he evolution of Test etween business Behavior Driven Developm ree principle ouna at nctg:// ehaviour-ariven Business and technology should refer to the same system in the same way Any system should have an identified,verifiable value to the business Upfront analysis,design,and planning all have a diminishing return 【21]
Chapter 1 [ 21 ] Also check Fit, http://fit.c2.com and Slim (Simple List Invocation Method), http://fitnesse.org/FitNesse.UserGuide.SliM, as an alternative to Fit. Lately, a new trend named Behavior Driven Development has gained some popularity and in a very brief description can be understood as the evolution of Test Driven Development. It aims to provide a common vocabulary between business and technology people in order to increase mutual understanding. Behavior Driven Development can be expressed as a framework of activities based on three principles (more information can be found at http://behaviour-driven. org): • Business and technology should refer to the same system in the same way • Any system should have an identified, verifiable value to the business • Upfront analysis, design, and planning all have a diminishing return
Getting Started with Testing To apply these principles,business people are usually involved in writing test case scenarios in a high level language and use some tool,such as jbehave into codthat expresse hese scenn the same test scenario in a programming language. Test case scenario As an illustration of this technique here is an oversimplified example. This scenario is: Given I'm using the Temperature Converter When I enter 100 into Celsius field. Then I obtain 212 in Fahrenheit field It would be translated into something similar to: enter mCelsius=celsius: assertEquals(fahrenheit, verter.celsiusToFahrenheit } Performance tests Perform ance tests measure performance characteristics of the components in a ation do early und 【221
Getting Started with Testing [ 22 ] To apply these principles, business people are usually involved in writing test case scenarios in a high level language and use some tool, such as jbehave (http://jbehave.org). In the following example, these scenarios are translated into code that expresses the same test scenario in a programming language. Test case scenario As an illustration of this technique here is an oversimplified example. This scenario is: Given I'm using the Temperature Converter. When I enter 100 into Celsius field. Then I obtain 212 in Fahrenheit field. It would be translated into something similar to: @Given("I am using the Temperature Converter") public void createTemperatureConverter() { // do nothing } @When("I enter $celsius into Celsius field") public void setCelsius(int celsius) { mCelsius= celsius; } @Then("I obtain $fahrenheit in Fahrenheit field") public void testCelsiusToFahrenheit(int fahrenheit) { assertEquals(fahrenheit, TemperatureConverter.celsiusToFahrenheit (mCelsius)); } Performance tests Performance tests measure performance characteristics of the components in a repeatable way. If performance improvements are required by some part of the application, the best approach is to measure performance before and after some change is introduced. As is widely known, premature optimization does more harm than good, so it is better to clearly understand the impact of your changes on the overall performance
Chapter 1 The introduction of the Dalvik IIT compiler in Android 2.2 changed some optimization patterns that were widely used in Android development.Nowadays, every recommendation about performance improvements on the Android developer's site is backed up by performance tests. System tests iona of tests like ·GUI tests ●Smoke tests ·Performancetests 。Installation tests Android testing framework Android proit wth speanced r suit ramework extending the industry dard Ju tes needed ols is in ost and str The key features of the Android testing environment include: thenit framework that provide system objects An instrumentation framework that lets tests control and examine the application. Mock versions of commonly used Android system objects Tools for running single tests or test suites,with or without instrumentation. Instrumentation The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock e ore e h 【231
Chapter 1 [ 23 ] The introduction of the Dalvik JIT compiler in Android 2.2 changed some optimization patterns that were widely used in Android development. Nowadays, every recommendation about performance improvements on the Android developer's site is backed up by performance tests. System tests The system is tested as a whole and the interaction between the components, software and hardware, is exercised. Normally, system tests include additional classes of tests like: • GUI tests • Smoke tests • Performance tests • Installation tests Android testing framework Android provides a very advanced testing framework extending the industry standard JUnit with specific features suitable for implementing all of the testing strategies and types we mentioned before. In some cases, additional tools are needed but the integration of these tools is in most cases simple and straightforward. The key features of the Android testing environment include: • Android extensions to the JUnit framework that provide access to Android system objects. • An instrumentation framework that lets tests control and examine the application. • Mock versions of commonly used Android system objects. • Tools for running single tests or test suites, with or without instrumentation. • Support for managing tests and test projects in the ADT Plugin for Eclipse and at the command line. Instrumentation The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock components required by the application to run. For example, you can create mock Contexts before the application starts and let the application use them
Getting Started with Testing All interaction of the application with the surrounding environment can be controlled using this approach.You can also isolate your application in a restricted environm ues returned by ng per a for ContentProvider Astandard Android project has atior As an illustrative example,assume your project has a manifest like this rsion-1 0u coding="utf-8"7 xmlns:android="http://sc .android.com/apk/res/android package="com.example.aatg.sample" android:versionCode="1" android:versionNar "1.0" sactivity android:name". android:label-"@string/app_name"> <intent-filter> "android.intent.action.MAIN"/> "android.intent.category.LAUNCHER"/> </intent-filter> </activity> </appl android:minsdkVersion"7/> In this case,the correlated Test project will have the following AndroidManifest.xml: <?xml version="1.0"encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="con example.aatg.sample.test" android:versionName1.0 android:label="@string/ar <uses-library android:name-"android.test.runner"/> </application> uses-sak an id:minSdkVersion-7/> cPackages"com.example.aatg.sample 【241
Getting Started with Testing [ 24 ] All interaction of the application with the surrounding environment can be controlled using this approach. You can also isolate your application in a restricted environment to be able to predict the results, forcing the values returned by some methods or mocking persistent and unchanged data for ContentProvider, databases, or even the filesystem content. A standard Android project has its tests in a correlated project that usually has the same project name but ends with Test. Inside this Test project, the AndroidManifest.xml declares the Instrumentation. As an illustrative example, assume your project has a manifest like this: <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.aatg.sample" android:versionCode="1" android:versionName="1.0"> <application android:icon="@drawable/icon" android:label="@string/app_name"> <activity android:name=".SampleActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name= "android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> <uses-sdk android:minSdkVersion="7" /> </manifest> In this case, the correlated Test project will have the following AndroidManifest.xml: <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.aatg.sample.test" android:versionCode="1" android:versionName="1.0"> <application android:icon="@drawable/icon" android:label="@string/app_name"> <uses-library android:name="android.test.runner" /> </application> <uses-sdk android:minSdkVersion="7" /> <instrumentation android:targetPackage="com.example.aatg.sample
Chapter1 android:name-"android.test.InstrumentationTestRunner android:label-"Sample Tests"/ </manifest> Here the Instrumentation package is the same package as the main application with the.test suffix added. Then the Instrumentation is declared specifying the target package and the test runner,in this case the default custom runner android.test. InstrumentationTestRunner. Also notice that both,the application under test and the tests are Android applications with their corresponding APKs installed.Internally,they will be sharing the same process and thus have access to the same set of features. When you run a test application,the Activity Manager(http://developer instrumenta ion framew ances o apik di the with the application Test targets During the evolution of your development t romthect your fests would be targete y,and speed of testing on an emulator to the unavoidable final testing on the specific devices you intend your application to be run on,you should be able to run on all of them. There are also some intermediate cases like running your tests on a local JVM virtual machine on the development computer or on a Dalvik virtual machine or Activity, depending on the case Every case has its pros and cons,but the good news is that you have all of these alternatives available to run your tests. The emulator is probably the most powerful target as you can modify almost ons for your e ab e to h all o the uatio ter to 【251
Chapter 1 [ 25 ] android:name="android.test.InstrumentationTestRunner" android:label="Sample Tests" /> <uses-permission android:name=" android.permission.INJECT_EVENTS" /> </manifest> Here the Instrumentation package is the same package as the main application with the .test suffix added. Then the Instrumentation is declared specifying the target package and the test runner, in this case the default custom runner android.test. InstrumentationTestRunner. Also notice that both, the application under test and the tests are Android applications with their corresponding APKs installed. Internally, they will be sharing the same process and thus have access to the same set of features. When you run a test application, the Activity Manager (http://developer. android.com/intl/de/reference/android/app/ActivityManager.html) uses the instrumentation framework to start and control the test runner, which in turn uses instrumentation to shut down any running instances of the main application, starts the test application, and then starts the main application in the same process. This allows various aspects of the test application to work directly with the main application. Test targets During the evolution of your development project your tests would be targeted to different devices. From the simplicity, flexibility, and speed of testing on an emulator to the unavoidable final testing on the specific devices you intend your application to be run on, you should be able to run on all of them. There are also some intermediate cases like running your tests on a local JVM virtual machine on the development computer or on a Dalvik virtual machine or Activity, depending on the case. Every case has its pros and cons, but the good news is that you have all of these alternatives available to run your tests. The emulator is probably the most powerful target as you can modify almost every parameter from its configuration to simulate different conditions for your tests. Ultimately, your application should be able to handle all of these situations, so it is much better to discover the problems upfront than when the application has been delivered