RadGrad provides "unit" and "integration" tests. Both are designed to be run from the command line and useful for continuous integration.
Unit tests are tests that run only on the server side, and which focus on verifying that the RadGrad data model (i.e. the set of Collection classes) work as intended.
Integration tests are initiated from the client side, and test to ensure that client-server interactions work as intended. Currently, integration tests only check that Meteor method implementations function correctly. We do not yet have UI tests, such as tests that would be implemented using Selenium or some other browser driver.
Each collection class contains its tests in a "sibling" file. For example, unit tests for CourseCollection.js are located in CourseCollection.test.js. Its integration tests that focus on its Meteor Methods are located in CourseCollection.app-test.js.
The test file names are important: Meteor wants unit tests to be in files with the suffix
test.js, and integration tests to be in files with the suffix
Many tests require the database to be initialized with test values. RadGrad provides "database fixture" files for this purpose. See the DB fixture chapter for more details.
Running the tests
To invoke the unit tests, use this command:
This will implicitly run ESLint over the code base first, then run the unit tests (i.e. those files with a
test.js suffix). Here's a sample invocation with some lines elided for brevity:
There should be no server or client failures listed. There will also be no client tests at all. In RadGrad, all unit tests occur on the server side.
Ubuntu running issue
On some linux installations, for example Ubuntu the tests might hang and never end. This is due to missing libraries that nightmare needs. To fix this issue run:
This will install xvfb and all of its dependencies.
To run a subset of the tests you can set the environment variable
MOCHA_GREP matches the name of the test as defined in the
describe statement those tests will run.
Setting the MOCHA_GREP environment variable
Structure for a Collection Unit Test
RadGrad collection have five required methods.
- define: Creates a new document in the collection. Returns the document's id.
- update: Updates a document in the collection.
- removeIt: Removes a document from the collection.
- dumpOne: Returns a JSON object suitable for defining the document.
- checkIntegrity: Checks each document in the collection for integrity. Returns an array of problems.
All of our unit test have a standard format. We ensure that, at a minimum, we test the five methods.
To help simplify the testing process, we create one or more functions to make a sample document for the collection. These functions are defined and exported in a file named Sample.ts. The SampleCourses.ts defines and exports three functions,
getRandomGrade. We use these functions in other tests.
The standard format looks something like:
The above five tests ensure that our collection's basic functionality works. If you define other methods for your collection then you should create more tests after the base five. For example, the CourseCollection tests has additional tests.
Integration tests check that client-level code can interact with the server side appropriately. To invoke the integration tests, run this command:
This will run the integration tests (i.e. those files with a
test-app.js suffix). Here's a sample invocation, again with some lines elided:
As you can see, in contrast to unit tests, no server-only tests were invoked.
You can reduce the number of tests that are run by using the
MOCHA_GREP environment variable, as discussed above.
Miscellaneous testing issues.
Here are a few issues regarding tests.
- Arrow function use with Mocha is discouraged. See http://mochajs.org/#arrow-functions.