
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I see I have done a poor job at showing a good & proper example, so please take a look at this:<div><br></div><div><ul class="MailOutline"><li><a href="https://github.com/mikedeboer/mozAsync/blob/master/examples/browser_aboutHome.orig.js">https://github.com/mikedeboer/mozAsync/blob/master/examples/browser_aboutHome.orig.js</a></li><li><a href="https://github.com/mikedeboer/mozAsync/blob/master/examples/browser_aboutHome.js">https://github.com/mikedeboer/mozAsync/blob/master/examples/browser_aboutHome.js</a></li></ul><div><br></div><div>This is the browser_aboutHome.js unit test code vs. a rewritten version with AsyncTest.</div><div><br></div><div>The NLOC difference is minimal (~100 lines), but the more significant improvement here is the structure that is proposed as uniform.</div><div><br></div><div>Mike.</div></div><div><br></div><div><div>On Apr 22, 2013, at 7:23 PM, Jared Wein <<a href="mailto:jwein@mozilla.com">jwein@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Mike,<br><br>Thank you for correcting me regarding framework vs. library. Please see my responses inline.<br><br>----- Original Message -----<br><blockquote type="cite">From: "Mike de Boer" <<a href="mailto:mdeboer@mozilla.com">mdeboer@mozilla.com</a>><br>To: "Jared Wein" <<a href="mailto:jwein@mozilla.com">jwein@mozilla.com</a>><br>Cc: "Firefox Dev" <<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>Sent: Monday, April 22, 2013 12:59:10 PM<br>Subject: Re: Simplify async code-flows and unify unit tests<br><br>Hi Jared,<br><br>Thanks for the feedback! Please read my comments inline too...<br><br>On Apr 22, 2013, at 6:11 PM, Jared Wein <<a href="mailto:jwein@mozilla.com">jwein@mozilla.com</a>> wrote:<br><br><blockquote type="cite">Hi Mike,<br><br>Thanks for writing this up. Please see my comments inline.<br><br>----- Original Message -----<br><blockquote type="cite">From: "Mike de Boer" <<a href="mailto:mdeboer@mozilla.com">mdeboer@mozilla.com</a>><br><br>What about them unit tests?<br><br>Design goal: create a simple, minimalistic framework that provides<br>a<br>clear, unified API to create unit tests that is as easy to use for<br>sync code flows as for async ones.<br><br>Rationale: unit tests are 'hot' code. They are modified as often -<br>perhaps even more - as functionality it covers changes, especially<br>in TDD environments. They serve as documentation for the code they<br>cover. When tests fail, they usually don't on 'your computer', but<br>somewhere else, like on the build infrastructure. When that<br>happens,<br>someone will open the unit test and try to understand what is<br>going<br>on.<br><br>In all these cases it is hugely beneficial to a) know that most<br>of the unit tests are written in the same structure and b) are<br>structured in such a way that they're easy to read by someone<br>other<br>than you.<br></blockquote><br>It seems to me that adding another testing framework exacerbates<br>the problem of unit tests not being written in the same structure.<br></blockquote></blockquote><br>What is your response to this?<br><br><blockquote type="cite"><blockquote type="cite">I believe that some of the features of this unit testing framework<br>actually make it quite hard to read by someone else. For example,<br>below you mention that tests can be commented out by placing an<br>exclamation point at the beginning of the test description. This<br>seems like a very obscure and non-obvious trick that won't be<br>caught by many people without extensive documentation reading.<br></blockquote><br>I'm afraid you misunderstood me: this is not a unit testing<br>framework, but a library that will enable us to write unit tests in<br>a uniform format in *together* with the existing test frameworks:<br>Mochitest and XPCShell. Please note that I'm using NodeJS style<br>assertions here as an example. Perhaps I picked that one poorly, but<br>I hope that you can fill in the gap.<br><br>The most important thing about commenting out a unit test with a "!"<br>is to allow more flexibility during a TDD workflow. This whole thing<br>is meant as a tool for developers, not TBPL maintainers. Another<br>example is the Growl notifications; they would not work and not make<br>any sense on our build servers, it's just there to make your life a<br>tad easier when doing TDD.<br><br>The "<" in the test name is meant to signal out a test case and run<br>only that specific one. This is something that is practically useful<br>when doing TDD.<br></blockquote><br>Many test frameworks will stop the test after failing the first assertion. Mochitest doesn't, so disabling a test while authoring isn't so much of a necessity. Regardless, we also have todo() which you could use while writing the test if you so please.<br><br><blockquote type="cite"><blockquote type="cite"><br><blockquote type="cite"><br>This is an example of a minimal test:<br><br><br>AsyncTest([<br>{<br>name: "Minimal Test",<br>reporter: "tap",<br>tests: {<br>"it should execute this test": function(next) {<br>Assert.equal(typeof next, "function", "'next' should be a callback<br>function");<br>next();<br>},<br>"! it should NOT execute this test": function(next) {<br>Assert.ok(false, "BAM!");<br>next();<br>},<br>"it should be aware of the correct context": function() {<br>Assert.ok(this["it should execute this test"], "The function ought<br>to<br>be accessible");<br>}<br>}<br>}<br>]);<br><br></blockquote><br>Have you tried coupling in the Mochitest asserts? As it currently<br>stands, the example of using the NodeJS Assert's aren't that<br>useful for seeing how hard it might be to get this integrated in<br>our setup.<br></blockquote><br>Looks like I already spilled the beans above :) Like I said… the<br>assertion style in a matter of choice; AsyncTest conforms to<br>whatever (as it's not a framework)<br><br><blockquote type="cite"><br>It's unclear to me how AsyncTest provides something that isn't<br>available today with Mochitest. What I do see though is that<br>adopting another testing framework will create more work for the<br>people who work on TBPL as well as developers who need to learn<br>the special rules and syntax of another testing framework.<br></blockquote><br>I hope you can see now that this thing is not a framework, but a<br>simple library that would improve our code quality if we were to<br>make more out of the benefits that TDD and other XP practices have<br>to offer.<br></blockquote><br>I think this conversation is too hard to discuss in the abstract. The sample code provided doesn't relate close enough to how we actually write tests.<br><br>This may be better discussed if we use a test from mozilla-central as an example. The following test could have been written before the code-under-test was written, aka TDD:<br><br><a href="http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/test/browser_pageshow.js">http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/test/browser_pageshow.js</a><br><br>How would this testing library make this test easier to read? What issues do you see with this test?<br><br>Thanks,<br>Jared<br></blockquote></div><br></body></html>