a) I think that's a fine number of tests for a module this simple, which is itself an argument in favor of small modules. And I think it's four more assertions than anyone implementing this inline in a project would have.
b) The details of this particular project are orthogonal to the philosophy of small modules generally. Whether or not this module is well implemented or well tested has no real relation to whether or not it is a good idea to compose tiny modules.
a) It's about half of what I'd write for my own, where I would make sure to test all edge cases (e.g. input string being longer than padding length) as well as Unicode characters. Writing expectations is cheap, fixing bugs later isn't.
b) I agree, but you were the one offering "well-testedness" as an argument :)
You are assuming well tested is referring to unit tests, rather than the wealth of developers depending on and running it in their projects daily.
Don't forget how many different targets there are for JavaScript, even if you had a test environment with limitless budget, it wouldn't compare to having a popular package on NPM.
