Testing Strategies Openki
Testing Meteor
Test ensure long-term quality of the app when it grows bigger and more complicated. The worth of Software lies in it's ability to be constantly changed. If this is not the case anymore, it's legacy. Tests are also the most complete way to describe the expected behaviour of the code and should be considered as part of the documentation for developers.
Ideas
- It would be helpful to know or see, which parts of the app are tested (coverage report)
- It would be nice to have isolated integration tests that do not rely on a database.
Acceptance tests
- Good to check if something breaks in the ui which is really hard to test
- Good to test translations (does the translation change if the user sees his own profile or the one from somebody else?)
- Describes a flow that a user would click on the frontend
Some Guidelines
- Isolation of tests is something good
- Writing components with testing in mind is a good thing (../variable in templates might violate that)
- For an app like Openki, where you might have to bootstrap users, courses events and more, it would be helpful to have test helping classes that facilitate the bootstrapping (Factory methods, see Testing Docs).
Tests with --full-app
- It loads test files matching .app-test[s]. and .app-spec[s]..
- It does eagerly load our application code as Meteor normally would.
- Sets the Meteor.isAppTest flag to be true (instead of the Meteor.isTest flag).
- Needed for acceptance tests
- Not necessarily needed for integration tests, things can be mocked as well
- These tests are slow and should be used if it's really needed
Test isolation
You can reset the database:
- with xolvio:cleaner package, see https://guide.meteor.com/testing.html#test-data
- Testing puplications wihtout having the cleint to subscribe
- add test utils
- for each component, write an integration test or a test for the data subscription and one that tests the template with expected data
Testing Templates with data in isolation
See example
Reference: https://guide.meteor.com/testing.html#isolation-techniques
Fixtures
- Meteor.methods for tests, used with Meteor.call
- define Factory functions to mock objects
- There are ways to mock db entries on the client only without need to add the entries to the database see Mocking the database
Todos
- Remove arrow functions in tests, see https://guide.meteor.com/testing.html#testing-types
- Add a coverage report (it seems there is not library, yet...)
- Write 3-4 solid Acceptance Tests that you would do manually to check if things still work the right way
Recommendations for future test writing
Where to write tests?
- Write the tests there, where you'll expect the biggest changes in future development. This will give confidence when making bigger changes.
- Do not write tests for things that are not yet stable in the aftermath, you'll waste too much time adapting the tests.
Edited by PonyM