More info re. inline unit testing
gavinorland opened this issue · 10 comments
Further to a chat with @bebraw I'm raising this as an issue here:
I was looking at this part of the book and I found myself wondering, if you wrote your code like this:
const assert = require('assert');
const add = (a, b) => a + b;
assert(add(1, 1) === 2);
module.exports = add;
That is to say, including testing code inside your modules instead of having tests separate and using a test runner, how would this affect the bundling and running of the app? At what point would the tests reveal themselves to either pass or fail? Maybe a little could be said about this.
I thinks this example isn’t correct: there should be a condition that checks that the script wasn’t required but run directly.
But I don’t see any benefits of that approach ;-|
Without a condition it will run tests every time you use a module normally — it’s at least slow ;-)
Yeah, we should add an if block to guard against that. Good point.
And explain what’s the real life use case to do that ;-)
Would it make sense to jump straight to a separate tests? This might be a good chance to discuss certain runtime checking techniques, though.
I thinks yes, that’s what people usually do and this example creates more confusion than explains something in my opinion.
I like to briefly see things done in what perhaps seems the most obvious, but is in fact the wrong, way first, then to see why it would be wrong and then the correct way instead. Appreciate you can't do this all the time though.
I see the test would run every time the module was used here. Just wondered how that would manifest itself at bundling/runtime.
I simplified the section. Thanks.
I think this is resolved given I dropped the inline idea from the book.