COMP 313 / 413: Intermediate Object-Oriented Development Dr. Robert Yacobellis Senior Lecturer Department of Computer Science Week 10 Topics } More About Project 4 – only if not complete in Week 9 ◦ Group Exercise: create a Project 4 extended state diagram ◦ Note: save a copy for your team’s Project 4 submission!! } Testing in clickcounter and stopwatch } Possibly time to work on Project 4 in your Groups 2 Week 10 Topics } More About Project 4 ◦ Some Project 4 details ◦ Group Exercise: create a Project 4 extended state diagram } Testing in clickcounter and stopwatch } Possibly time to work on Project 4 in your Groups 3 Android Testing Fundamentals } Android recommends TDD and iterative development ◦ When developing a feature iteratively, you start by either writing a new test or by adding cases and assertions to an existing unit test. The test fails at first because the feature isn’t implemented yet: ◦ An IntelliJ IDEA project typically contains two test directories: androidTest that contains tests that run on a device or emulator, and test that contains (unit) tests that run on your local machine – Some of these may use mock objects or “test doubles” – Unit tests may use Robolectric to run on a normal JVM 4 Android Testing Framework } Key Android testing framework features ◦ As you know, Android test suites are based on JUnit – A JUnit test is a method that tests part of the application ◦ Android JUnit extensions provide component-specific test case classes, that include – Helper methods for creating mock objects – Methods that help control a component’s life cycle – See https://developer.android.com/training/testing/start/index.html for more information about Android testing ◦ Test suites are contained in test packages like applications – An app called com.mydomain.myapp has a test package name com.mydomain.myapp.test – Its tests are run by a test runner, eg, the androidx AndroidJUnitRunner ◦ Testing tools are available in IDEs and in command-line form 5 Android Testing Framework Run on a local JVM Run on an emulator or Android hardware 6 Instrumented versus Local Tests 7 Android Test Case Classes This is now deprecated 8 IntelliJ IDEA Test Structure } In IntelliJ IDEA Projects the “source sets” for source and device test code live in src/main and src/androidTest, respectively ◦ Java source code and resources live in java and res sub- directories of these Project directories – clickcounter & stopwatch Project tests don’t have resources ◦ This configuration is managed in the Project’s build.gradle file –https://developer.android.com/studio/build/ hasdetails related to using the Gradle plugin and build.gradle } You can run these Android tests on a device or emulator via the Android Debug Bridge (ADB) by right-clicking app in ClickCounter or Stopwatch in the Project view and selecting Run ‘All Tests’ or by changing to the Android view and running androidTest ◦ Note: shapes-android-java did not have Android test code 9 Robolectric Project Test Structure } Robolectric allows Android Activities to be unit tested in a Java Virtual Machine as opposed to on a device or emulator } Robolectric dependencies in IntelliJ IDEA are also specified in the build.gradle file, and test source files live in a deep sub-directory of src/test/java ◦ The sub-directory structure matches the package structure in src/main/java (in Projects stopwatch, clickcounter, shapes) } All directories under src/test/java are visited when you run gradlew testDebug in Terminal or run test in the Android view ◦ Doing this runs the <ActivityName>Robolectric.java file, which extends the primary Activity test defined in src/androidTest ◦ Doing this also finds and runs all of the Test.java files in src/test/java; these files may extend unit test files in main/java 10 Android Activity Testing } ActivityInstrumentationTestCase2<T> used to be used in Stopwatch, but has been deprecated in more recent versions of Android since Android 2.2 (API 8) } Instead, AndroidX now supplies a Test Support Library with JUnit support up to JUnit 4.13 plus other features ◦ If you are creating an instrumented JUnit 4 test class to run on a device or emulator, your test class must be prefixed with the @RunWith(AndroidJUnit4.class) annotation and create an “AndroidTestRule” to connect tests with the class under test ◦ See the next slides for how stopwatch and clickcounter do this ◦ Note that the corresponding ActivityTestRule is also now deprecated in Android – replaced by ActivityScenarioRule 11 Android Activity Testing } Here’s stopwatch’s code to set up Android testing (this class lives in a subdirectory of src/androidTest) @RunWith(AndroidJUnit4.class) @SmallTest // see this website for more details public class StopwatchActivityTest extends AbstractStopwatchActivityTest { @Rule public ActivityTestRule<StopwatchAdapter> activityRule = new ActivityTestRule<>(StopwatchAdapter.class); // connect test to app Activity @Override protected StopwatchAdapter getActivity() { return activityRule.getActivity(); // returns the Activity under test } } // https://developer.android.com/reference/android/support/test/rule/ActivityTestRule.html 12 stopwatch testing class diagram 13 Android Activity Testing } Here’s clickcounter’s code to set up Android testing (this class lives in a subdirectory of src/androidTest) @RunWith(AndroidJUnit4.class) @SmallTest public class ClickCounterActivityTest extends AbstractClickCounterActivityTest { @Rule public ActivityTestRule<ClickCounterActivity> activityRule = new ActivityTestRule<>(ClickCounterActivity.class); // connect test to app Activity @Override protected ClickCounterActivity getActivity() { return activityRule.getActivity(); // returns the Activity under test } } // https://developer.android.com/reference/android/support/test/rule/ActivityTestRule.html 14 clickcounter testing class diagram 15 Android Testing Instrumentation } You can invoke callback methods in test code that allow you to execute an Activity’s life cycle step by step } Testing that an Activity saves and restores its state: // Start the main activity of the application under test mActivity = getActivity(); // getActivity() is a key method that’s part of the instrumentation API // in this case it causes onCreate() to be called the first time as the Activity is started // Get a handle to the Activity object’s main UI widget, a Spinner mSpinner = (Spinner)mActivity.findViewById(com.android.example.spinner.R.id.Spinner01); // Set the Spinner to a known position mActivity.setSpinnerPosition(TEST_STATE_DESTROY_POSITION); // Stop the activity – The onDestroy() method should save the state of the Spinner mActivity.finish(); // finish() causes onDestroy() to be invoked // Re-start the Activity – the onResume() method should restore the state of the Spinner mActivity = getActivity(); // getActivity() will cause onResume() to be invoked // Get the Spinner’s current position int currentPosition = mActivity.getSpinnerPosition(); // Assert that the current position is the same as the starting position assertEquals(TEST_STATE_DESTROY_POSITION, currentPosition); 16 stopwatch UI Tests – androidTest } StopwatchActivityTest.java in the src/androidTest directory delegates to AbstractStopwatchActivityTest.java in src/main; its test methods do not run in the UI thread, but instead use it: ◦ testActivityCheckTestCaseSetUpProperly – Activity launched OK ◦ testActivityScenarioRun performs these checks: the initial displayed value is 0, and Start/Stop can be clicked after sleeping 5.5 seconds the displayed value is 5 àdisplayed value checks are run in the UI thread ◦ testActivityScenarioRunLapReset performs these checks: display is 0, press Start/Stop, wait 5+ seconds, expect time 5 press Reset/Lap, wait 4 seconds, expect time display still 5 press Start/Stop, expect time display still 5 (turns off Lap) press Reset/Lap, expect time display 9 (makes time visible) press Reset/Lap , expect time display 0 17 stopwatch-android-java Reminder: stopwatch State Machine 18 stopwatch Unit Tests – gradlew testDebug 1 } gradlew testDebug runs StopwatchActivityRobolectic.java in src/test, which extends and runs all the tests in AbstractStopwatchActivityTest.java (above) } Test.java in …/model/clock runs tests in DefaultClockModelTest: ◦ Both tests override the onTickListener to be an atomic int ◦ testStopped – after sleeping 5.5 seconds, that int is still 0 ◦ testRunning – after sleeping 5.5 seconds the int is 5 } Test.java in …/model/time runs tests in DefaultTimeModelTest: ◦ testPreconditions – the model’s runtime == 0, laptime <= 0 ◦ testIncrementRuntimeOne – times are correct after one tick ◦ testIncrementRuntimeMany – times are correct after one hour ◦ testLapTime – after 5 ticks the runtime is +5, laptime is +0; after 5 ticks after “clicking” Lap runtime is +10, laptime is +5 } Both Default…Tests delegate to corresponding Abstract…Tests 19 stopwatch Unit Tests – gradlew testDebug 2 } Test.java in …/model/state runs tests in DefaultStopwatchStateMachineTest (again, implemented in AbstractStopwatchStatemachineTest): ◦ There’s a dependency on an inner mock class that implements TimeModel, ClockModel, and StopwatchUIUpdateListener and replaces their methods with simple integer manipulations, etc. ◦ testPreconditions – tests that the initial state is Stopped ◦ testScenarioRunLapReset – verifies the following scenario: time is 0, press start, wait 5+ seconds, expect time 5, press lap, wait 4 seconds, expect time 5, press start, expect time 5, press lap, expect time 9, press lap, expect time 0 20 clickcounter UI Tests – androidTest } ClickCounterActivityTest.java in the src/androidTest directory delegates to AbstractClickCounterActivityTest.java in src/main; its test methods run in the UI thread on a device or emulator: ◦ testActivityTestCaseSetUpProperly – Activity is launched OK ◦ testActivityScenarioIncReset performs these checks: clicking Reset displays 0, enables Inc, and disables Dec clicking Inc displays 1; Inc, Dec, and Reset are all enabled clicking Reset again displays 0, Inc is enabled, Dec disabled ◦ testActivityScenarioIncUntilFull performs these checks: clicking Reset displays 0, enables Inc, and disables Dec clicking Inc repeatedly increments the display until full when display is full, Inc is disabled, Dec and Reset enabled ◦ testActivityScenarioRotation checks that the displayed value remains the same if the device is rotated 21 Implicit clickcounter State Machine 22 clickcounter Unit Tests – gradlew testDebug } gradlew testDebug runs ClickCounterActivityRobolectic.java in src/test; it extends and runs all the tests in AbstractClickCounterActivityTest.java (above) } Test.java in test/…/misc/boundedcounter/model is also run by gradlew testDebug and runs all tests in SimpleBoundedCounterTest: ◦ testInitiallyAtMin – the counter is initially at its minimum value ◦ testIncrement – one is added to the displayed counter value ◦ testDecrement – one is subtracted from the max counter value ◦ testFullAtMax – the counter is at its maximum value when full ◦ testEmptyAtMin – the counter is at its minimum when emptied ◦ testPreconditions* – the initial counter has distinct max & min ◦ testGet* – the counter value is consistent across gets ◦ testIsFull* – the counter isn’t full if decremented at full ◦ testIsEmpty* – the counter isn’t empty if incremented at empty * inherited from AbstractCounterTest 23 Project 4 – Functional Requirements – Slide 1 of 2 } The timer has the following controls: ◦ One two-digit display of the form 88. ◦ One multi-function button. (Clicking the button causes a click event.) } The timer behaves as follows (part 1 of 2): ◦ The timer always displays the remaining time in seconds. ◦ Initially, the timer is stopped and the (remaining) time is zero. ◦ If the button is pressed when the timer is stopped, the time is incremented by one up to a preset maximum of 99. (The button acts as an increment button.) ◦ If the time is greater than zero and three seconds elapse from the most recent time the button was pressed, then the timer beeps once and starts running. (When the remaining time is greater than 0 the clock model (see stopwatch) is used to send tick events to the state machine.) 24 Project 4 – Functional Requirements – Slide 2 of 2 } The timer behaves as follows (part 2 of 2): ◦ While running, the timer subtracts one from the time for every second that elapses. (Caused by a clock model tick event.) ◦ If the timer is running and the button is pressed, the timer stops and the time is reset to zero. (The button acts as a cancel button.) ◦ If the timer is running and the time reaches zero by itself (without the button being pressed), then the timer stops and the alarm starts beeping continually and indefinitely. ◦ If the alarm is sounding and the button is pressed, the alarm stops sounding; the timer is now stopped and the (remaining) time is zero. (The button acts as a stop button.) ◦ The timer handles rotation by continuing in its current state. } Your group activity is to create a set of unit tests for Project 4; you do not need to create the tests, just a list of proposed tests (do include rotation!) 25 Project 4 – Events There are only two kinds of events in Project 4: } Button Click events (always processed in all states) } Clock Tick events (ignored in stopped and alarm states unless a Clock Tick is used to repeatedly play a “beep” for the alarm) 26 Project 4 Tests to Consider (not complete) } From clickcounter (button clicking and displayed timer value): ◦ testActivityTestCaseSetUpProperly: Activity launched OK ◦ testActivityScenarioIncUntilFull: clicking Inc repeatedly increments the display until full (the timer will display 99) ◦ testInitiallyAtMin: the counter is initially at its minimum (0) ◦ testIncrement: one is added to the (initial) counter value ◦ Optional: testGet: the counter value is consistent across gets } From stopwatch (counting down or “running” the timer): ◦ testIncrementRuntimeOne: times are correct after one tick ◦ testLapTime: after 5 ticks the runtime is -5 (the displayed timer value should be 5 less than its initial value which must be >= 5) } Items in italics need to be changed for the simple timer! ◦ Eg, counteràdisplayed time, incrementàclick, … 27 Project 4 – Group Activity } Your group activity is to create a set of unit tests for Project 4; you do not need to create the tests, just a list of proposed tests } If you haven’t finished your Project 4 (timer) extended state diagram, do that first so the unit tests will make more sense } Submit both of these on Sakai by July 29 using the assignment ◦ They can be submitted by different people in your larger Group } Do include a test that rotation saves the timer state in Project 4 } If there’s time left after you finish these, work on Project 4 in your larger groups 28 Week 10 Topics } More About Project 4 ◦ Some Project 4 details ◦ Group Exercise: create a Project 4 extended state diagram } Testing in clickcounter and stopwatch } Possibly time to work on Project 4 in your Groups
