Download Automated Unit Testing Android Studio

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
References:
https://developer.android.com/studio/test/index.html - intro
https://developer.android.com/training/testing/start/index.html - getting started
https://developer.android.com/training/testing/unit-testing/index.html - intro to unit testing
https://developer.android.com/training/testing/unit-testing/local-unit-tests.html - local unit tests
https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html Instrumented tests
http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html - Mockito
Setup:
https://developer.android.com/topic/libraries/testing-support-library/index.html#setup – setting
up your environment
Testing through the GUI:
https://developer.android.com/training/testing/ui-testing/index.html
https://developer.android.com/training/testing/ui-testing/espresso-testing.html http://www.vogella.com/tutorials/AndroidTestingEspresso/article.html - Testing from the GUI
example.
Notes on rules:
http://cwd.dhemery.com/2010/12/junit-rules/
http://stackoverflow.com/questions/13489388/how-does-junit-rule-work
https://carlosbecker.com/posts/junit-rules/
Test Types and Location
The location of your test code depends on the type of test you are writing. Android Studio provides
source code directories (source sets), for the following two types of tests:
Local unit tests
Located at module-name/src/test/java/.
These are tests that run on your machine's local Java Virtual Machine (JVM). Use these tests to
minimize execution time when your tests have no Android framework dependencies or when
you can mock the Android framework dependencies.
At runtime, these tests are executed against a modified version of android.jar where
all final modifiers have been stripped off. This lets you use popular mocking libraries, like
Mockito.
Instrumented tests
Located at module-name/src/androidTest/java/.
These are tests that run on a hardware device or emulator. These tests have access
to Instrumentation APIs, give you access to information such as the Context of the app you
are testing, and let you control the app under test from your test code. Use these tests when
writing integration and functional UI tests to automate user interaction, or when your tests have
Android dependencies that mock objects cannot satisfy.
1. To add a local unit test, expand the test folder. To add an instrumented test, expand
the androidTest folder.
2. Right-click on the Java package directory and select New > Java Class.
3. Name the file and then click OK.
Your local unit test class should be written as a JUnit 4 test class.
Unlike the previous approach to Android unit testing based on JUnit 3, with JUnit 4, you do not
need to extend the junit.framework.TestCase class. You also do not need to prefix your test
method name with the ‘test’ keyword.
To create a basic JUnit 4 test class, create a Java class that contains one or more test methods.
A test method begins with the @Test annotation and contains the code to exercise and verify a
single functionality in the component that you want to test.
To run a test case, right click the test file name in the explorer window on the left and select
“Run”.
Note, local unit tests are much easier to run than instrumented tests. To run instrumented tests,
you have to install Android Support Repository and update your gradle file.
To run instrumented test, as described here: https://developer.android.com/topic/libraries/testingsupport-library/index.html#setup I had to install Android Support Repository (from Android Studio UI):
From (SDK Manager):
You also need to update the .gradle file for the module (in app folder):
defaultConfig {
…
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
And
dependencies {
testCompile 'org.mockito:mockito-core:1.10.19'
// You may have to change the version below to match
// the version above for appcompat-v7
androidTestCompile 'com.android.support:support-annotations:25.0.0'
androidTestCompile 'com.android.support.test:runner:0.5'
// Set this dependency to use JUnit 4 rules
androidTestCompile 'com.android.support.test:rules:0.4'
// Set this dependency to build and run Espresso tests
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'
}
More on writing automated tests
android.test.AndroidTestCase was deprecated in API level 24. Use InstrumentationRegistry instead. New
tests should be written using the Android Testing Support Library.
A mocking framework can be used to isolate your unit from its dependencies.
For testing Android apps, you typically create these types of automated unit tests:


Local tests: Unit tests that run on your local machine only. These tests are compiled to run
locally on the Java Virtual Machine (JVM) to minimize execution time. Use this approach to run
unit tests that have no dependencies on the Android framework or have dependencies that can
be filled by using mock objects.
Instrumented tests: Unit tests that run on an Android device or emulator. These tests have
access to instrumentation information, such as the Context for the app under test. Use this
approach to run unit tests that have Android dependencies which cannot be easily filled by using
mock objects.
In your Android Studio project, you must store the source files for instrumented tests at modulename/src/androidTest/java/. This directory already exists when you create a new project and contains
an example instrumented test.
If your unit test has no dependencies or only has simple dependencies on Android, you should run your
test on a local development machine. This testing approach is efficient because it helps you avoid the
overhead of loading the target app and unit test code onto a physical device or emulator every time
your test is run. Consequently, the execution time for running your unit test is greatly reduced. With this
approach, you normally use a mocking framework, like Mockito, to fulfill any dependency relationships.