On 03/06/2014 14:16, Mike de Boer wrote:
Indeed, I’m used to the NodeJS/ Mocha flow of writing tests as fast, or even faster, as writing the implementation of a feature. I could group tests, isolate one, hook in a debugger at any point and more. This is something I miss while working on Fx and to be honest: I still crave for more than a year later.
So I'm not used to the "NodeJS/Mocha" 'flow' of writing tests. Can you explain what the big difference there is? I find it hard to believe the names of the assertion functions are the one big thing making tests take much longer to write...
Node is inherently single-threaded (unless you bolt on extra stuff), which makes the runtime environment a lot more controlled than say, a web browser. IME, the main issue in writing correct browser mochitest tests (which is what I write 95% of the time) is focus, timeouts, and event sequences (ensuring you wait for X before doing Y), OS differences (and sometimes, try/staging vs. my local machine differences) and making it easy and obvious (how) to trigger UI actions in a test, and the ease of debugging (which has gotten better now that we have --break-on-failure and --jsdebugger).
That all seems to have preciously little to do with assertions, log output, or TDD per se. In other words, if we want to make the experience of writing tests easier, I don't think a unified assertion framework is where we should be focusing our effort.
Can you expand on why you think that that is such an important component here, and how it compares with mocha/node?
~ Gijs _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
