Less IO for your Java Unit Tests

http://eng.wealthfront.com/2010/11/less-io-for-your-java-unit-tests.html

by eishay • 16 years ago

32 5 16 years ago

eng.wealthfront.com

mdaniel• 16 years ago

This is an awesome idea. Well, let me restate that: this is an awesome geek hack.

I posit that this kind of tomfoolery is required because (in my experience) profiling tools are (1) expensive (2) hard to use (3) inaccurate [could be due to #2] or the combination of the preceding.

Also, my current employer's tests run in the order of magnitude of hours, and I doubt very seriously that they are I/O bound (or network bound) in the manner that this page discusses. But, again falling back on the "hard to know without tooling", I couldn't state with any confidence exactly what the problem is with the tests, so this may be a great start toward finding out.

athaio• 16 years ago

mdaniel: I've seen no profiling tools that can reliably perform this kind of automated profiling and force people to think about certain issues. You're spot on—the tooling is more about raising awareness than making your build faster, or slower. There are many legitimate reasons to have a very-slow build. It should be the choice of a fully-informed human to figure out the trade off and make a conscious decision.

sr_young• 16 years ago

our build is now using this, thank you. discovered some nasty io.

pascal-louis• 16 years ago

Can you share which IO was discovered? Anything that is general bad practices others can learn from?

arosien• 16 years ago

FYI you can clone this code from the blog post (with lots of other goodness) at http://code.google.com/p/kawala or https://github.com/wealthfront/kawala.

Less IO for your Java Unit Tests

Related Stories