Improving Code Coverage

We use the coverage report to find an untested function, and test it’s side effect first, then we test the if statement.

[tahaiftekhar]

if someone having problems and errors in istanbul like I am having. Try installing 'nyc' and config like this in Package.json:

"scripts": {
"test": "nyc mocha index.test.js",
"coverage": "nyc --reporter=lcov --reporter=text-lcov nyc mocha index.test.js"
},

it is the same

[Artem]

In the test for .addEquipment() 3:56 -- I was sure that we MUST be mocking out calls to other methods ( .calculateEquipment() ) and checking if they were called (with the help of spies).

I can agree there is value in testing the side effects (armorBonus quantity): it shows the business logic requirements...
But as far as we are doing UNIT tests: what if .calculateEquipment() got broken?
-> then we would have .addEquipment() broken as well as a consequence as it internally calls .calculateEquipment()
(and we didn't touch addEquipment's at all, while the method would have been working otherwise).

Thus, what you show here is kinda INTEGRATION test, isn't it?
Or as long as we are testing one CLASS we shouldn't be mocking its OWN methods, but only the methods of other classes?

Hoping to hear about your thoughts! Thanks :)

[frskGG]

do you have some github to get full source, or can you upload it somewhere? Thanks