CS 185C/286 - Lecture 7

Cay S. Horstmann

Lecture 7 Quiz 1

Put your answer into Piazza.

What is true about the setSchedules method in the Film class?

1. It is called in FilmParser.
2. It is called in FilmParserTest.
3. It is not necessary since one can just call getSchedules.
4. It is poor design since a Film should be immutable.

Lecture 7 Quiz 2

What is the result of the query http://mobile.cinequest.org/mobileCQ.php?type=schedules&day=2013-03-02?

1. All films that play on March 2
2. The user's schedule for March 2
3. All program items that are scheduled for March 2
4. All events that happen on March 2

Project Ideas

1. Modernize Android client for Android 4, including tablets
2. Improve device integration with Android and iPhone client: location, phone, schedule, contacts, etc.
3. HTML5 Cinequest client
4. Hemepath counter app
5. Samsung S-Pen
6. Port Cinequest app (films only, not schedule) to Windows phone

Today's Lecture/Lab

• Testing Concepts
• The Android Unit Testing Library

Testing Concepts

• Unit testing: Test code components in isolation
• Integration testing: Test the integration between components
• White/black box testing: Design tests with/without knowledge of the program structure
• Smoke test: A quick test for obvious failures
• Alpha/beta test: Test phase with engineers/end-users
• Stress testing: Checking whether the application can withstand high load
• Usability testing: Testing whether end-users can navigate the UI
• Test-driven design: Designing software together with test cases
• Test automation: Running tests without human intervention
• Continuous integration: Running automated tests after every checkin

The Unit Testing Philosophy

• Classical model: Programmers write code, throw it over the fence to testing department
• Advantage: Programmers need not be experts in test automation
• Problem: Generally poor coverage of internal features
• Unit tests are authored by programmers
• ...some preferably before writing any code
• Advantage: Can help clarify API
• Advantage: Testability is built into the API
• Advantage: Better test coverage of nontrivial internals
• Most commonly used framework: JUnit

  Never in the field of software development have so many owed so much to so few lines of code.—Martin Fowler

JUnit Test Case

• Put test cases in companion classes
• Mark test methods with @Test (JUnit 4) or testXXX (JUnit 3)
• All annotated methods/methods named testXXX are executed
• Can have other methods in test class
• Use assertXXX methods to test for expected behavior

  import org.junit.Test;
  import static org.junit.Assert.*;
  public class StackTest
  {
     @Test
     public void pushPop()
     {
        Stack<String> stk = new Stack<String>();
        String name = "Harry";
        stk.push(name);
        String ret = stk.pop();
        assertEquals(ret, name);
     }
  } 

Testing For Exceptions

• When testing an API, often want to test specified exceptions
• Use annotation parameter

  @Test(expected = IndexOutOfBoundsException.class) 
  public void empty() 
  { 
      new ArrayList<Object>().get(0); 
  }

• When exception happens, test passes. When it doesn't happen, test fails
• If an unexpected exception occurs, test fails
• All exceptions are caught by the test runner—the suite isn't terminated

Fixtures

• Often want to set up data structures before test runs
• Setup code typically shared between tests
• Annotate method with @Before
• Run before each test
• @BeforeClass method runs once before all @Before methods
• If test classes use inheritance, superclass @Before/@BeforeClass methods run before subclass
• @After/@AfterClass for teardown

Mock Objects

• Object that acts for another object during testing
  • because the original is too heavyweight
  • because the original doesn't exist yet
• The original and mock should implement a common interface
• Example: JavaSEPlatform

Using JUnit Effectively

• Build parallel test hierarchy (src / test)
• Make a test class when (before?) you make a class
• Come up with one nontrivial test case right away
• Don't test trivial stuff (such as getters/setters)
• If something makes you nervous, write a test case
• When you fix a bug, add a test case that would have caught it
• Group test cases with the same @Before/@After into one test class
• Use inheritance to factor out common @Before/@After
• Run all tests before you check in your code (duh)
• Be aware of the limitations of unit tests—no replacement for integration testing

Android Testing Support

• JUnit 3 Extension
• Provides mock objects that simulate app lifecycle
• Provides useful assertions for Android programming
• monkeyrunner automates UI testing. Write scripts in Python that start an app, simulate user actions, takes screenshots, etc.
• Exerciser Monkey: Stress test tool. Sends pseudorandom stream of events to the program
• StrictMode

Reading Before Next Class

• Testing Android
• MonkeyRunner

Lab

• Bring your laptop to the lab
• You will work with a buddy
• One of you writes code, the other types up answers
• Switch roles each lab
• Submit lab work to git

Spinner Test Tutorial Setup

1. We will follow this tutorial.
2. Open the Android SDK Manager and make sure that you have the Samples for SDK installed. If not, install them now. Don't install updates—that takes too long.
3. Make a new Android project from existing sources. Select sdk/samples/android-version/Spinner inside your ADT. Be sure to check "Copy into workspace".
4. Now follow the instructions at “To create a new test project for the SpinnerTest application, follow these steps: ”
5. Complete the tutorial and answer the questions on the next slide.

Spinner Test Tutorial Questions

• After “Adding an initial conditions test”: That test seems a little contrived. Give an example of a more interesting test that one might want to make in the Homework 2 application.
• After “Adding a UI test”: Why do they send keys and not mouse clicks?
• After “Adding state management tests”: How would you apply this to the Homework 2 application?