-
Notifications
You must be signed in to change notification settings - Fork 0
Test Plan
As a team focused on test-driven development, a test plan is an important part of a complete project concept. However, due to the wide variety in architectures that form a part of the MTM project, we must present separate testing plans for each portion.
The server is the closest the MTM project comes to a traditional software development situation: it runs on server machines using Ruby, a standard scripting language. As such, it can use a more standard unit-testing framework than the Android or iPhone components; for this project, the team has chosen Rack::Test.
To test the server, the team has constructed a set of unit tests that are broken down as follows:
- Tests are separated into categories based on the the objects they act on (e.g. points, trails)
- Individual tests act on separate API endpoints hosted by the server
Server tests will be developed before the accompanying server functionality. All written server tests are available in the Server project's test/server_spec.rb.
As the Android application targets a mobile device, testing is slightly more complex than for the server. However, since the Android OS and applications are based on the Java language, several test frameworks (including the team's choice JUnit) are readily available and simply take some small tweaks to work with the platform.
As the server is responsible for testing data as a whole (see the section on integration, below), the Android tests need only deal with local objects and their manipulation, as well as the XML parsing that must take place to make data available to the Android application. These tests are provided in three major chunks in the Android Test folder from the Android project:
- Base tests, which deal with application activities such as launching, closing, and handling input
- Object tests, which ensure the functionality of local representations of trail objects
- XML tests, which confirm the proper workings of XML parsing from server-provided data
All the tests are implemented well ahead of Android implementation and are held in a distinct Eclipse project so as to maintain a clean separation of tests and application code. Note that the XML testing is accomplished partly with the help of a well-defined XML schema.
The iPhone platform's testing options are perhaps the most limited of the three components. The predominant unit testing framework is OCUnit, an Apple-endorsed but independently developed framework for the Objective-C language. As with the Android platform, the iPhone tests will be responsible only for local data representation. In addition, the currently available developer toolkits do not fully support unit testing.
Despite these limitations, unit tests for data representation objects are available for the iOS application are available in the Classes folder in the iPhone project. Tests have been written for trails, trail points, and interest points.
Due to the system architecture's specification that code be held as separately as possible, with the server receiving the bulk of duplicate code and all common design, it becomes the responsibility of the server project and its maintainer to handle integration testing. Such tests - primarily those dealing with the API call responses and common data storage - will fall under the server's unit testing.
The other portion of integration testing is handled by having equivalent API tests in all mobile platform unit test sets - ensuring that both client and server adhere to the API specification will provide for a proper project integration.