ABS Plug-in Quality Assurance - Test plan


The purpose of this plan is to systematise and coordinate the testing activities of the ABS Eclipse plug-in. This test plan summarizes:

  • Test objects
  • Test strategy
  • Mapping of resources and requirements for performing the test plan.

Test objects

System overview

Following functionality is supported by the plug-in:

  • Create ABS projects and gather ABS models in these projects by adding one or more ABS files.
  • Translate ABS models into both Java and Maude.
  • Run ABS models either with Java or Maude with the use of the integrated Eclipse run dialogs
  • Editor with syntax highlighting.
    • Content assist (CTRL-SPACE) giving completion proposals.
    • Content outline.
    • Marking code problems (syntax and semantical errors).
    • Marking of location types.
  • Module explorer showing the module structure of ABS projects supporting wizards for the creation of new * ABS projects
    • ABS modules (new or existing file)
    • ABS classes
    • ABS interfaces
  • Debugging of ABS models including
    • Navigating through the COG and task structure
    • Stepping of one task
    • Displaying stack frames
    • Displaying current values of variables
    • Tracking of the code execution by highlighting the current code line in the editor.
  • Setting of preferences relevant for the ABS plug-in

System environment

The ABS plug-in provides an Integrated development environment for creating programs and model created with the ABS modeling language. Therefore, the ABS plug-in supports a developer in creating ABS models.

The plug-in itself is integrated into the Eclipse platform, and can used on every platform eclipse runs on. The plug-in uses a pre-existing ABS Compiler and Frontend and uses pre-existing structures for debugging the ABS model.

Test strategy

For testing the ABS plug-in one week (part-time) is considered. Testing is done in three steps:

  • Unit tests of functionality that is decoupled from the Eclipse framework
  • Walkthrough of basic functionality
  • Code review

The step "walkthrough" is optional. Only if the unit testing and code review steps are finished in time, walkthroughs will be conducted.

Unit testing

Unit tests will be done for classes that can be decoupled from the Eclipse framework. In these respective classes only methods that do not require user interface interaction will be tested. Additionally, functionality connected to Label and content providers will be covered by walkthroughs and will not be unit tested.

Following classes should be tested:

  1. eu.hatsproject.absplugin.console.ConsoleManager
  2. eu.hatsproject.absplugin.editor.outline.ABSContentOutlineUtils
  3. eu.hatsproject.absplugin.internal.IncrementalModelBuilder
  4. eu.hatsproject.absplugin.navigator.ModulePath
  5. eu.hatsproject.absplugin.navigator.NavigatorUtils
  6. eu.hatsproject.absplugin.util.InternalASTNode
  7. eu.hatsproject.absplugin.util.UtilityFunctions
  8. eu.hatsproject.absplugin.util.WizardUtil
  9. eu.hatsproject.absplugin.debug.SchedulingStrategy
  10. eu.hatsproject.absplugin.debug.scheduling.GUIScheduler
  11. eu.hatsproject.absplugin.debug.scheduling.NStepScheduler
  12. eu.hatsproject.absplugin.debug.schedulung.RandomScheduler
  13. eu.hatsproject.absplugin.debug.scheduling.RunToLineScheduler
  14. eu.hatsproject.absplugin.debug.scheudling.StepOverScheduler


In addition to unit testing, walkthroughs of all basic use cases will be done using the eclipse plug-in.

Problems and failures will be recorded using the problem list for walkthroughs that can be found in the testing/templates folder of the plugin svn directory.

Code review

In order to assure code quality, all packages and their respective classes should be reviewed. To start with, for the review following checklist can be used:

  • Javadoc
    • Are all public and protected methods bigger than 5 LoC documented using Javadoc?
    • Are all public variables documented using Javadoc
    • Is the Javadoc useful and meaningful?
    • Do Javadoc parameters match the actual method parameters?
    • Do Javadoc comments contain throws clauses where necessary?
    • Are exceptional cases like null arguments documented?
  • Coding style
    • Is lots of code commented out?
    • Is the code understandable and provides comments at crucial places?
    • Do method names reflect the functionality of the code?
    • Do all methods handle errors reasonably?
    • Are stack traces printed out where the error could have been handled better?
    • Is the visibility of methods reasonable?
    • Is System.out.println() used to document or debug code?
  • Understandability
    • Could some code of a class be extracted to increase the understandability of the code?
    • Does the class have an appropriate size in order to support understandability?
    • Are the number of methods reasonable? Are the classes over-refactored?
    • Are comments used to increase understandability at crucial points?
  • Packaging
    • Is the partitioning of the code in the respective class reasonable?