Looks like he also has a video: http://www.infoq.com/presentations/Crazy-Fast-Build-Times-or-When-10-Second… On 06/27/2013 03:20 PM, Vincent Massol wrote: The blog post was negative about separating fast tests from slow tests and I think anything which could fail the build should be regarded similarly. It's annoying to build something and then push and find that it violates a rule which you didn't see in the local build. I'm pretty cold for selenium right now, the cynical view is you wait a long time for useless information. Those tests flicker so often that you really don't know if there's a problem until you've seen 3 consecutive failures so I usually "push and check back tomorrow". The "storage-tests" are Commons HTTP based functional tests and although they're not as fast as unit tests, they turn out to be far more predictable than selenium. The cool part about integration tests is you get a huge amount of code coverage with very little test code. I see each LoC as a liability (including tests) but of course each uncovered LoC is a much greater liability so if there's a test which offers to cover a lot of code, I am interested, it just has to be fast and not flicker. The problem with our integration tests is they're slow and they flicker. Cjdns has no actual integration tests, it has 4,440 lines of unit tests which run in 0.537 seconds and although I may be misreading, gcov seems to say says I have 68.89% coverage. One technique I've used to improve that number is to bring up 3 full nodes (in the same process) and send packets between them by mocking the UDP interfaces so there is no dependence on network/kernel behavior. This test runs in 0.05s and has never flickered. For testing the TUN device I do what Dan was talking about, I have a single test which verifies that it works, all other tests mock it. In our case bringing up the whole XWiki engine takes an embarrassingly long time but we might be able to get good performance on non-windows platforms by bringing up the engine then firing the fork() syscall, giving us N tests for the price of 1. I don't understand this. I'd love to see the last maven build but the major alternatives such as Ivy and Gradle perform just as bad or worse. I'm facing the exact same problem with cjdns, I chose cmake "the fast build system" and now I've concluded that I'm not going to get a fast build unless I script everything manually. For cjdns, I'll use node.js because it's async APIs allow me to keep any number of CPUs (potentially on different machines) saturated and almost never have to wait on the disk. To script everything for XWiki manually would be a pretty massive undertaking, that said, it would probably take a dedicated developer months to get fast builds anyway. buildr might be interesting if it is async. I know Make is async but I'm not sure just how the author is using it, assuming it's GNU Make he's referring to. IMO if a build system is not async is just trading one white elephant for another. For a hot rebuild on my laptop with no altered files I get 3.585s which is really annoying because it's basically just finding files where the mtime is newer than X. $ time find ./ -wholename '*build*' -prune -or -wholename '*.git*' -prune -o -mtime -7 -print > /dev/null real 0m0.018s This is the main reason why I'm planning on throwing cmake overboard. Probably the single biggest thing that could improve the platform build would be dumping GWT. Since I'm playing with various WYSIWYG type editors as part of the Resilience project, I might be able to help with this but unfortunately no outside editor is going to understand the meaning of a macro so we're stuck either maintaining a fork or accepting degraded WYSIWYG functionality. Thanks, Caleb