> We don't have the two-way comms channel between the plugin and the fork in > surefire which means it's all precalculated.
Yes, I know. > There are certainly benefits/drawbacks > to both approaches. My personal use-case involves extremely long-running > tests and of > extreme variation in run-time, which seems to fit better with the > implementation > in surefire at the moment. I will disagree with you here. The project I mentioned was originally prepared for Apache Lucene and the tests in there are randomized and component-randomized so their execution time can vary by order of magnitude. I know for a fact that static statistics (even calculated for many runs) are not so good at scheduling even deadline for all slave JVMs because I observed this in practice. These stats are very useful for bootstrapping the process (scheduling initially longest tests first, for example) but they are not working for static scheduling in a dynamically changing situation. Don't get me wrong, I still think it's great for surefire to have static balancing, but it would be nice if dynamic balancing appeared some time in the future. :) > It's a fairly simple patch to write up, just needs a lot of tests ;) Yes, it does take a fair bit of testing, especially jvm crashing is tough because jvms emit logs to communication channels regardless of the content of System.out/err. We switch communication channels depending on jvm type detected at runtime, actually. The tests are in the project as well. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
