feat(server-tests): code coverage and e2e #505
Conversation
Changes: - add `mocha.conf.js` and use it as a `require` in `mochaTest` task - switch `should.js` for `mocha-chai` - change server-side test assertions to user chai assertions Breaking Changes: - should.js is no longer included, chai assertions should be used instead.
|
Depends on #500 |
Changes: - split server tests into `unit` and `e2e` type test - adjust `mochaTest` and `test:server` tasks to reflect the two types of tests - implement `grunt-mocha-istanbul` task for server-side code coverage - add `test:coverage` task - improve `mocha.conf.js` - add sinon, expect, and assert as globals to `server/.jshintrc-spec` - add `proxyquire` to the app for better stubbing in unit tests - improve test to reflect recent changes and to lay ground work for more coverage Grunt Task `test`: The grunt 'test' task now has a 'coverage' target. Used like so `grunt test:coverage`. This task will run istanbul for the server unit tests and e2e test separately. The resulting coverage reports will be placed in `coverage/(unit|e2e)`. There is also an option for the `test:coverage` task, possibilities for option are: - `unit` - `e2e` - `check` `test:coverage:check` will check the coverage reports for both `unit` and `e2e` and report whether or not they meet the required coverage.
kingcody
force-pushed
the
feature/mocha-istanbul
branch
from
bc21e25 to
dbbaa20
Compare
kingcody
changed the title
feat(server-tests): code coverage and e2e
|
@DaftMonk any thoughts on the direction I took with the tests/setup? |
|
Sorry, I only meant to merge #500 but I somehow must have merged this before I was able to review it. I have some questions/comments. I do understand you're trying to draw a distinction between unit tests and integration tests, but calling them e2e tests might be confusing, since we already have e2e tests with protractor. Don't really like using return statements in the expectations, they aren't really adding anything. I'm a bit confused about what the index.spec.js files are testing, and where the index.js is being tested from those tests. Edit: Nevermind, I see how these tests work now. Looks good, but I think I might want to make it a bit more clear where the stubs are being injected into the index file. |
|
Suggestions for e2e alternative name? I'm in no way bias. The return statements are because jshint see the assertion as just a property lookup. We can adjust |
|
Make stub injection clearer: comment proxyquire usage? Or do we need to break those definitions up more? |
| describe('.authenticate()', function() { | ||
|
|
||
| it("should authenticate user if password is valid", function() { | ||
| return user.authenticate('password').should.be.true; |
There was a problem hiding this comment.
|
Ok, not sure how I missed it or why I was getting |
Changes:
unitande2etype testmochaTestandtest:servertasks to reflect the two types of testsgrunt-mocha-istanbultask for server-side code coveragetest:coveragetaskmocha.conf.jsserver/.jshintrc-specproxyquireto the app for better stubbing in unit testsGrunt Task
test:The grunt 'test' task now has a 'coverage' target. Used like so
grunt test:coverage.This task will run istanbul for the server unit tests and e2e test separately.
The resulting coverage reports will be placed in
coverage/(unit|e2e). There is also an optionfor the
test:coveragetask, possibilities for option are:unite2echecktest:coverage:checkwill check the coverage reports for bothunitande2eandreport whether or not they meet the required coverage.