Question

My situation, as some background:

I’m writing a small javascript library which uses window.requestAnimationFrame to perform its animation loop. Because that function isn’t standardised across the browsers yet, internally in the library it creates a polyfill-ish function in a closure.

var requestAnim = window.requestAnimationFrame
    || window.webkitRequestAnimationFrame
    || ...
    || function () { ... };

The issue here is that this makes it quite hard for me to test this code now. Previously, when it was using setTimeout, I would override that global function in the tests to simulate a number of frames passing synchronously.

Anyway, to the point of the question:

Right now, it seems like my options are either to leave some of my code untested, or to add extraneous features to the library with the sole purpose of making it easier to test. Neither of these options sound that great to me.

Without worrying too much about my specific case, in general, what should you do in this situation?

Answer 1

Yes, it is ok.

We don’t write tests for the sake of testing. Testing is an acknowledgement of the fact that we aren’t brillant enough to write and maintain code perfectly without safety checks. All test code serves one purpose and only one: to make a better product. This is true whether it lives in the /test folder or in the /src folder. Therefore it is a mistake to think “This is never called in production, therefore it is wrong to put it into /src!”

To be sure, there are other trade-offs to make, e.g. size (in an embedded product it makes a lot of sense to try everything you can to keep the /src folder small). But that is a completely different reason than merely “It’s test-related”.