I understand all that and I *think* you missed the header mentioning I was going off-topic…
Mike. On 03 Jun 2014, at 15:39, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote: > 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
