Comments on: Making unittest life better… http://oduinn.com/blog/2009/02/26/making-unittest-life-better/ Fri, 27 Jan 2012 15:12:34 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: John O’Duinn’s Soapbox » Welcome (back) Lukas! http://oduinn.com/blog/2009/02/26/making-unittest-life-better/#comment-31724 John O’Duinn’s Soapbox » Welcome (back) Lukas! Thu, 21 May 2009 15:27:54 +0000 http://oduinn.com/2009/02/26/making-unittest-life-better/#comment-31724 [...] If you’ve never met Lukas, you should know that last summer, Lukas arrived for her internship, and had barely unpacked when we handed her the entire unittest infrastructure without warning. With very little guidance, she took it all on. Lukas worked non-stop stabilizing and streamlining machine configs in a million-and-one little details, chasing intermittent unittest failures to figure out if they were caused by code bugs, testware bugs, RelEng bugs or IT bugs… or a combination! She was so great, we hired her as a part-time contractor when she was heading back to Seneca. In that role, she worked with catlee and myself to consolidate all the build and unittest machines into one shared pool (details here). This project massively simplified life in RelEng, improved end-to-end turnaround time for developers; more importantly, it was a pre-req to getting unittests running on TryServer, and also to separating out build from unittest for faster turnaround times (details here, here and here). All massive stuff. [...] [...] If you’ve never met Lukas, you should know that last summer, Lukas arrived for her internship, and had barely unpacked when we handed her the entire unittest infrastructure without warning. With very little guidance, she took it all on. Lukas worked non-stop stabilizing and streamlining machine configs in a million-and-one little details, chasing intermittent unittest failures to figure out if they were caused by code bugs, testware bugs, RelEng bugs or IT bugs… or a combination! She was so great, we hired her as a part-time contractor when she was heading back to Seneca. In that role, she worked with catlee and myself to consolidate all the build and unittest machines into one shared pool (details here). This project massively simplified life in RelEng, improved end-to-end turnaround time for developers; more importantly, it was a pre-req to getting unittests running on TryServer, and also to separating out build from unittest for faster turnaround times (details here, here and here). All massive stuff. [...]

]]> By: John O’Duinn’s Soapbox » Making unittest life better - whats next? http://oduinn.com/blog/2009/02/26/making-unittest-life-better/#comment-25223 John O’Duinn’s Soapbox » Making unittest life better - whats next? Wed, 25 Mar 2009 10:14:29 +0000 http://oduinn.com/2009/02/26/making-unittest-life-better/#comment-25223 [...] Since writing this post and then this post, we now have “unittests on try” running on production. Big tip of the hat to Lukas and Catlee for that! So, whats next on our “make unittest better” ToDo list? [...] [...] Since writing this post and then this post, we now have “unittests on try” running on production. Big tip of the hat to Lukas and Catlee for that! So, whats next on our “make unittest better” ToDo list? [...]

]]> By: John O’Duinn’s Soapbox » Unittest and l10n moved from “dedicated specialized slaves” to “pool of identical slaves” http://oduinn.com/blog/2009/02/26/making-unittest-life-better/#comment-23959 John O’Duinn’s Soapbox » Unittest and l10n moved from “dedicated specialized slaves” to “pool of identical slaves” Tue, 17 Mar 2009 06:44:11 +0000 http://oduinn.com/2009/02/26/making-unittest-life-better/#comment-23959 [...] Later, once we get past some unittest framework cleanup, we should be able to run unittests without requiring an additional unittest-specific build first (see blog for details). Once that’s fixed, we can then start running individual unittest suites concurrently on the pool-of-slaves, which means: [...] [...] Later, once we get past some unittest framework cleanup, we should be able to run unittests without requiring an additional unittest-specific build first (see blog for details). Once that’s fixed, we can then start running individual unittest suites concurrently on the pool-of-slaves, which means: [...]

]]> By: Axel Hecht http://oduinn.com/blog/2009/02/26/making-unittest-life-better/#comment-21885 Axel Hecht Thu, 26 Feb 2009 12:01:33 +0000 http://oduinn.com/2009/02/26/making-unittest-life-better/#comment-21885 Sounds like great stuff, good to see that we're fixing problems instead of throwing hardware at it. Also interesting to see how long we're already laborating on that issue. Looking at the complexity of your simple waterfalls, it sounds to me like we got to fix our reporting infrastructure before we can parallize tests runs, though. Folks already have a hard time to find the results of their builds, adding more boxes without having a display up for those doesn't sound like it would help and save developer time. Sounds like great stuff, good to see that we’re fixing problems instead of throwing hardware at it. Also interesting to see how long we’re already laborating on that issue.

Looking at the complexity of your simple waterfalls, it sounds to me like we got to fix our reporting infrastructure before we can parallize tests runs, though. Folks already have a hard time to find the results of their builds, adding more boxes without having a display up for those doesn’t sound like it would help and save developer time.

]]>