When I use this module, I almost always end up writing a test that looks like this:
test('expects a string', t => {
t.throws(() => {
fn([]);
}, 'Expected a string');
})
So I propose that we add this test into the app/test.js file because this module's boilerplate already adds in a throw if the first parameter is not a string, so we would actually be writing a test to cover the boilerplate's own logic (giving it 100% test coverage), but offers the benefit of helping users by scaffolding out a commonly-used test case.
It takes less time to delete a test from the test.js file (in the event that you don't need this unit test), than it would be to write this test out manually each time.
If you like the idea of adding this type of unit test to the module, I am happy to submit a PR. If not, then slap me across the face, and send me on my way.
When I use this module, I almost always end up writing a test that looks like this:
So I propose that we add this test into the
app/test.js
file because this module's boilerplate already adds in a throw if the first parameter is not a string, so we would actually be writing a test to cover the boilerplate's own logic (giving it 100% test coverage), but offers the benefit of helping users by scaffolding out a commonly-used test case.It takes less time to delete a test from the
test.js
file (in the event that you don't need this unit test), than it would be to write this test out manually each time.If you like the idea of adding this type of unit test to the module, I am happy to submit a PR. If not, then slap me across the face, and send me on my way.
Cheers. 🍺