Less IO for your Java Unit Tests(eng.wealthfront.com)
eng.wealthfront.com
Less IO for your Java Unit Tests
http://eng.wealthfront.com/2010/11/less-io-for-your-java-unit-tests.html
3 comments
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.
our build is now using this, thank you. discovered some nasty io.
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.
Can you share which IO was discovered? Anything that is general bad practices others can learn from?
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.