Skip to content

Testing

David Oberacker edited this page Sep 10, 2021 · 1 revision

Testing

The Framed.io project has a test infrastructure to run automated unit tests using the test-js kotlin module. Tests are automatically run during the build pipeline for the CI/CD. Currently, there is no framework for automated UI testing integrated.

Infrastructure

There is some infrastructure implemented for simplifying the testing of some components.

TestBase

The io.framed.util.TestBase class creates a example model containing most of the available model elements. By extending this class a test setup can use the setup model to run tests on without the need to write a model initializer for every test set. The structure of the generated model is as follows:

Package1
 | Compartment
 | | RoleType1
 | | RoleGroup1
 | \ \ RoleType2
 | Scene
 | \ RoleType3
 \ Class
 Package2

TestMatchers

The io.framed.util.TestMatcher class implements static matchers for pictogram testing. The implemented matchers test if the HTML DOM model supplied by the view-model classes is matching the expected structure. For nested or list view-model elements sub-matchers can be passed to validate child elements. For every child element a sub-matcher has to be specified or a assertion will fail. Matchers for the following pictogram elements are implemented:

  • TextFields
  • Checkboxes
  • InputFields
  • Sidebar
  • SidebarGroup
  • ContextMenu
  • ContextMenuButton

Existing Test Cases

In the following section described the existing tests, their extend and the methodology used.

Linkers

There are tests implemented for the following linkers:

  • RoleProhibitionLinker
  • RoleImplicationLinker
  • RoleEquivalenceLinker
  • RoleGroupLinker
  • FulfillmentLinker
  • ModelLinker

For these linkers a white-box, functionality, unit test methodology was used. The tests were written by the developer of the code. As a metric manually observed statement coverage was used.

As a base setup the aforementioned TestBase is used. This is then extended to fit the structure required for testing the particular linker.

The tests are focused on the editing constraints defined in the companion object to the linkers, and the view-model created by the linker. Regarding the view-model, mostly the Sidebar and ContextMenu are tested. The view-model for representing the object is often too complicated to be tested using this methodology.

To archive this, matchers for the different elements are required. This was outside of the scope of my additions to the project. Due to the usage of libraries for drawing connections, etc., the exact look of an element can not be determined using this method.

Model Elements

There are tests for the following model elements implemented:

  • ModelElement
  • ModelConnection

For these linkers a white-box, functionality, unit test methodology was used. The tests were written by the developer of the code. As a metric manually observed statement coverage was used.

The tests check if the uniqueness requirement for the model element ids are fulfilled.

Clone this wiki locally