Transitioning to strict mode
Claus Reinke
claus.reinke at talk21.com
Thu Feb 21 12:29:09 PST 2013
>> You still need more than statement or branch coverage. Otherwise,
>> we might get 100% "coverage" while missing edge cases
>>
>> function raise() {
>> "use strict";
>> if( Math.random()>0.5 || (Math.random()<0.5) && (variable = 0)) console.log(true);
>> else
>> console.log(false);
>> }
>>
>> raise();
>> raise();
>> raise(); // adjust probabilities and call numbers until we get
>> // "reliable" 100% branch coverage with no errors; then
>> // wait for the odd assignment to happen anyway, in
>> // production, not reproducably
> There is no "reliable 100% coverage" in this case. The coverage I guess is... probabilistic?
Yes, and yet current test coverage tools, even if they go beyond
statement coverage and test for branch coverage, will happily
give you a 100% coverage report (with a little tuning, even
repeatedly). That is why the page you linked to talks about levels
of test coverage beyond branch coverage, and why it is important
to know about such limitations.
Given the complexities of test suites and experience with irreproducible
bugs, testers might even be tempted to overlook the occasional random
test suite failure if it doesn't happen again on re-running the suite?
> I understand errors can be caught by a try-catch placed for other reasons, but whoever cares about
> transitioning to strict mode will be careful to this kind of issues.
I was thinking of services that need to stay up, no matter what
(restart first, check what happened later). At least, one can hope
that they would notice a Reference error in their logs.
> Other fixes for all the error cases are welcome as contributions.
Providing fixes is good. It would be even better if there was a tool
that pointed out any and all potential problem spots related to strict
mode introduction, flagging non-strict-safe functions for review
(Ariya's validator does only check syntax, not scoping or this, I think,
but might serve as a starting point).
But now we're into debugging strict-mode-related issues, instead
of using strict mode to reduce the likelihood of issues.
I used to be firmly in the (naïve?) strict-mode-is-better camp and
couldn't understand why switching everything to strict mode was
considered a bad idea. This thread has documented the reasons
why some coders are wary about the idea. If your page can help
to steer a way around the obstacles, even better.
Claus
More information about the es-discuss
mailing list