RTD is a test runner for Meteor. It's exactly like having a continuous integration server on your machine. Every time you save a file RTD will:
- Run all your unit tests in any browser [default: PhantomJS]
- Run all your acceptance tests in any browser [default: Chrome]
- Combine test coverage from unit and acceptance runs
- Check the coverage thresholds and provides a pretty report [default: 100%]
We have focused our efforts on making RTD as seamless and fast as possible. It will run in the background without bothering your workflow and you simply get pass/fail as you develop.
RTD is highly customizable. You can test using any browser, including mobile, and you can choose your testing framework like Jasmine (default), Mocha etc.
For growl notifications, you need to install a notifier if you don't already have it:
MAC: $ sudo gem install terminal-notifier LINUX: $ sudo apt-get install libnotify-bin
Next you need to move your meteor code into an app directory the structure of your application as follows:
├── <project root> │ ├── .git │ ├── app │ │ └── .meteor │ │ └── <your meteor code here>
You will also want to structure your tests as follows:
├── <project root> │ ├── .git │ ├── app │ │ └── .meteor │ │ └── <your meteor code here> │ ├── test │ │ └── acceptance │ │ │ └── fixtures │ │ │ │ └── <your fixture code here> │ │ │ └── <your end-to-end tests here> │ │ └── unit │ │ │ └── <your unit tests here> │ │ │ └── <THERE MUST BE ONE UNIT TEST AT LEAST>
Now you can add RTD to your package.json like in the example (you'll need all of the dev dependencies there too).
To have RTD run in development mode, you type:
$ ./node_modules/.bin/rtd or $ ./node_modules/.bin/rtd --debug
And to test your app once (for pre-commit or on a CI server) you type:
$ ./node_modules/.bin/rtd runOnce --debug
To see the actual coverage report in detail, go to http://localhost:8000/coverage
Enjoy using RTD
If you'd like to change any settings, you can do so by copying either or both of karma.conf.js and rtd.conf.js from <your project root>/test/rtd to <your project root>/test. RTD will use these settings file and you can also check them in as part of your project. Please see the config files themselves for what the settings do.
- Read our blog post on Unit-testing with Meteor
- Read our blog post on End-to-end testing with Meteor
- See an example of RTD with Meteor + Leaderboard sample app
The ability to capture and deal with feedback is a great indicator of quality, both of working practices and the end deliverable. Feedback comes in all shapes and sizes and the earlier feedback can be captured, the easier and cheaper it is to deal with.
What if we could get feedback in realtime? It's an ideal for sure, but consider the trends of Agile development, lean startups, super fast test executions with file watcher triggers and so forth. You could say we're not that far off from this ideal with all the magic efforts the community has put in.
From a developer's perspective, here are the key feedback areas and how they are detected:
|Feedback||Detection mechanisms||Currently Implemented|
|Code quality||Static analysis||Test Coverage|
|Regression||Automated testing||Unit & end-to-end acceptance|
Of course each one of those detection mechanisms needs to be implemented, and this is often missed out all together in an end-to-end deployment pipeline, let alone on an individual developer's machine. RTD is the toolset and wiring required to get the above-mentioned feedback locally, in realtime.