

Less IO for your Java Unit Tests - eishay
http://eng.wealthfront.com/2010/11/less-io-for-your-java-unit-tests.html

======
mdaniel
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
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
our build is now using this, thank you. discovered some nasty io.

~~~
arosien
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>.

