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]
- Combines test coverage from unit and acceptance runs
- Checks 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.
NOTE: Due to a bug in SocketIO, Karma doesn't work with the latest version of Node and therefore unit tests will fail. Downgrading to v0.10.5 works.
$ npm i -g email@example.com firstname.lastname@example.org email@example.com grunt-cli selenium-webdriver jasmine-node
If you have any issues with phantomJS, you may need to do this
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
If you get an openssl error, you should do this:
$ rvm implode $ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer) $ rvm autolibs enable $ rvm reinstall all --force
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>
RTD will live under the test directory. You can use a git sub-module as follows: (advised method as you'll get updates to RTD as we do them)
$ cd <your project root> $ mkdir -p ./test/acceptance/fixtures; mkdir ./test/unit; touch ./test/acceptance/fixtures/empty.js; $ git submodule add firstname.lastname@example.org:xolvio/rtd.git ./test/rtd; cd test/rtd; npm install;
Once the above runs, you should see this:
├── <project root> │ ├── .git │ ├── app │ │ └── .meteor │ │ └── <your meteor code here> │ ├── test │ │ └── acceptance | │ │ └── fixtures | | │ │ └── empty.js | │ │ └── <your end-to-end tests here> │ │ └── rtd | │ │ └── <a whole bunch of stuff> │ │ └── unit | │ │ └── <your unit tests here>
Now every time you start development, just run this: (the first time will take a few minutes as selenium-server & chromedriver are downloaded)
$ cd <your project root>/test/rtd $ ./rtd or $ ./rtd --debug
Enjoy using RTD
To see the actual coverage report in detail, go to http://localhost:8000/coverage
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.