-
Notifications
You must be signed in to change notification settings - Fork 58
Test Conventions
These test conventions will come into force at the end of iteration 14, when the Great Refactoring will occur.
In this document when discussing filenames, the words Spec
and Tests
can normally be substituted for each other.
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.
- 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 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.
- where appropriate, test files should be named
${classDirectlyUnderTest}ISpec.groovy
- note the
I
beforeSpec
in the filename! - where it's not obvious then more creative names can be used
Functional tests should be split per-controller.
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
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
.
/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 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
/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 Object should:
- create data and save them in the database
- be named
${controller}BaseSpec.groovy