Hacker News new | ask | show | jobs
by kalak451 5627 days ago
Ruby’s Test::Unit library (which we use for Basecamp’s tests) creates a new instance of the test class for each test. Not only that, but it holds onto each of those instances, so if your test suite includes thousands of tests, then the test suite will have thousands of TestCase objects.

On the Java side, JUnit does exactly the same thing. However I usually see this manifest itself as out of memory errors rather than a time sink. Over the years I have gotten some VERY strange looks from clients when I null out instance variables in my tear down methods. Usually takes a couple of hours of explanation to gain some level of acceptance, if not understanding.

1 comments

What are the benefits of holding onto each instance?
I don't believe Test::Unit does this intentionally; it's just a side-effect of the implementation (load all tests into an array, and iterate over the array).
JUnit stores all of the meta data about each test case in the test instance itself, so all of the reporting is based off of these classes. It has always puzzled me why it was done this way, why not just store a collection of "meta-data" objects and report off of them (allowing the test instances to be garbage collected,) but I assume it would break most of reporting the plugins/tools to change it now.

Note this is for the older 3.x versions of JUnit, I'm not 100% this is still true for the 4.x line.