
Writing Testable JavaScript - mnemonik
http://www.adequatelygood.com/2010/7/Writing-Testable-JavaScript
======
jal648
The problem I'm encountering is creating a decent suite of javascript tests
that can be run easily in a continuous integration setup. Most things I've
seen involve some sort of polling in a Selenium test. Not sure if anyone has
any better ideas, but this has been a serious headache for me the last few
months.

------
sdevlin

        We could simply add a getTemplate() method, but then we'd be adding methods to the public interface solely to allow testing, which is not a good approach.
    

It seems like his solution does this anyway by exposing the supplant function.
Despite the underscore, it's not private; it's that brand of smile-and-a-wink
private popular in python. I'm not a big fan of that. I like to keep the
interface simple for consumers of the class, and even if I know to ignore
underscored members, it's still noise.

That said, I don't have a better solution. Maybe the trade-off is worth it for
well-tested software. I suppose you could structure your code so that objects
can respond to some debug or test flag that forces them to expose their
internals, but that might be a lot of work for little benefit. At the end of
the day, maybe it's best to call this "good enough" and get back to work.

------
adamilardi
Singletons could be reset using a beforeclass(Reset data before a test suite
is ran) or beforetest(Reset data before a test is run) type method. This is
built into test frameworks for java, python and others.

------
chrismealy
That testCases trick is pretty neat.

