-
Notifications
You must be signed in to change notification settings - Fork 451
WIP: Tests! Coverage even! #154
base: master
Are you sure you want to change the base?
Conversation
Current coverage:
All coverage except Files which are not loaded by a test, such as |
looks good to me. Can I merge or should I hold off for a while? |
It won't break anything, to be sure, since it doesn't touch the actual code, but there will be a fair bit more munging to make the tests less repeatitive / a bit easier to reason about, as I get further. I want to get 100% function coverage at minimum, but I feel good about getting at least close to 100% branch. This is fine to be a long-running PR, as it won't be touching the actual source, so no conflicts. |
Sounds good, I'll keep it open. |
Updated coverage, all work on
CognitoUser tests now use a mock Just The only real code left after that is Looks like the valid session checks always call the callback as a node callback if they fail - it's possible I broke this with the ES2015 port. It should be safe to update the code to be correct, but I'd prefer to add those as failing but ignored tests then fix with a separate PR once this is done. |
Implemented fully mocking other modules, giving more accurate test coverage for tested files:
There are in fact a few other missed methods to test in I did find a few more probable bugs, check for comments around |
@simonbuchan just landed some changes to
I'm using configuration that looks something like this in my testing project:
{"babel": {
"presets": [
"es2015"
],
"env": {
"test": {
"plugins": [
"istanbul"
]
}
}
},
"nyc": {
"include": [
"src/**/*.js"
],
"exclude": [
"node_modules"
],
"require": [
"babel-register"
],
"sourceMap": false,
"instrument": false
}} |
New summary with
|
And simplify module mocking.
@simonbuchan it's great that you want to do this, but it's hard to get it "through the door" if it's such a big PR. Would you mind breaking it up into smaller chunks? |
To be honest? I hit a bit of a wall trying to figure out testing the stuff in the If I were to pick this up again now from scratch, I would probably switch to Now that you've reminded me, I might try taking another look at this now I've gotten more experience. When you say "breaking it up", do you mean for code review purposes? The normal method I've seen and we've used internally has been to create a "landing branch" and create small PRs for review only merging to that, then merging that in without needing to review all at once. |
@simonbuchan I like the idea of a landing branch |
Uses:
babel-plugin-istanbul
to workaround NYC not understanding babel-compiled codeStill work in progress, but with an initial test working for the scary
authenticateUser()
I think it's worth starting to get feedback on if this is going the right direction.Run
npm test
to just test, andnpm run coverage
to run with coverage and generate reports, currently:coverage
Getting NYC going correctly with babel is a bit sensitive right now, but Istanbul and NYC are moving fast right now, so I'm expecting some of the issues to disappear.
You can debug the tests if you install the HEAD version of AVA and use IDEA IntelliJ/WebStorm 2016.3 EAP: https://github.com/avajs/ava/blob/master/docs/recipes/debugging-with-webstorm.md