Test Conventions

Test Conventions

These test conventions will come into force at the end of iteration 14, when the Great Refactoring will occur.

Notes

In this document when discussing filenames, the words Spec and Tests can normally be substituted for each other.

General

In general, Spock specs should be written. There will likely be occasions when JUnit tests are more suitable because of requirements to extend existing test classes, and in these cases then writing JUnit tests is acceptable.

Unit

• 1 test per class
• test class should be in same package as class under test (obviously in the test/ directory in the filesystem though)
• tests should be named ${className}Spec.groovy
• no concrete instance of any class other than the one under test should be found in a unit test (in this case, it's an integration test)

Integration

Location

Integration tests should be stored in folders/packages relating to the area of the application they are testing, specifically:

• /test/integration/frontlinesms2/domain (database, GORM tests)
• /test/integration/frontlinesms2/controller
• /test/integration/frontlinesms2/service
• /test/integration/frontlinesms2/config

If it's unclear which package a test should be located in, then leaving it in frontlinesms2 is ok - we will clear this up later if it gets cluttered.

Naming

• where appropriate, test files should be named ${classDirectlyUnderTest}ISpec.groovy
• note the I before Spec in the filename!
• where it's not obvious then more creative names can be used

Functional

Functional tests should be split per-controller.

Naming and location

Very simple tests

If all functional tests for a controller will fit in one class, the class should be located and named as so:

/test/functional/frontlinesms2/${controllerName}FSpec.groovy

More complicated tests

Functional tests for a controller which span multiple files should reside in a separate directory relating to the controller name/URL.

As tests become longer, files should be split along the following lines:

• views
  • list view
  • individual view
  • per entity (e.g. Contact, Group, CustomField)
• CED
  • per entity (e.g. Contact, Group, CustomField)
  • per CED task (i.e. Create, Edit, Delete)

Per-entity CED tests should be named ${entityName}${cedOperation}Spec.groovy.

Examples

/test/functional/frontlinesms2/MySimpleFSpec.groovy
/test/functional/frontlinesms2/contact/ContactViewSpec.groovy
/test/functional/frontlinesms2/contact/ContactListSpec.groovy
/test/functional/frontlinesms2/contact/ContactCreateSpec.groovy
/test/functional/frontlinesms2/contact/ContactEditSpec.groovy
/test/functional/frontlinesms2/contact/ContactDeleteSpec.groovy
/test/functional/frontlinesms2/contact/CustomFieldFSpec.groovy
/test/functional/frontlinesms2/contact/GroupViewSpec.groovy
/test/functional/frontlinesms2/contact/GroupCedSpec.groovy

Page Objects

Page Objects should:

• be used where possible
• be reused where possible, to help the developer to find already existing page, the "Page" will prefix the name of the file so they all appear together.
• be defined in their own file
• be named Page${controller}${action}.groovy

Examples

    /test/functional/frontlinesms2/contact/ContactPage.groovy
    /test/functional/frontlinesms2/contact/ContactShowPage.groovy
/test/functional/frontlinesms2/contact/ContactCreatePage.groovy
/test/functional/frontlinesms2/contact/ContactCreateGroupPage.groovy

Base Objects

Base Object should:

• create data and save them in the database
• be named ${controller}BaseSpec.groovy