Well, for one thing, it's not self-documenting. For the other, unless
I'm missing something, we won't notice if an assertion is fixed and
replaced with another one.
And yes, catching when an assertion is fixed would clearly be useful, too.
Cheers,
David
On 20/11/14 18:14, L. David Baron wrote:
On 11/21/14 8:49 AM, L. David Baron wrote:
On Friday 2014-11-21 12:51 +0100, David Rajchenbach-Teller wrote:
Well, for one thing, it's not self-documenting.
We should comment them better (i.e., have a bug on each one, and
point to the bug in a comment on the expectAssertions line). I
wasn't
I wasn't aware that we could whitelist an individual NS_ASSERTION. How
do we do that?
On 20/11/14 17:24, Boris Zbarsky wrote:
This sounds lovely.
Note that in C++ for some of our test suites we already have this with
NS_ASSERTION and for all test suites we have it with MOZ_ASSERT.
Assuming,
I believe that we can provide something less fragile than that.
On 20/11/14 17:56, Boris Zbarsky wrote:
Ah, we can't. We can whitelist the number of assertions in a mochitest
(or a number range if the number is not quite stable), but not the text
of the assertion.
-Boris
On 20/11/14 17:56, Boris Zbarsky wrote:
Ah, we can't. We can whitelist the number of assertions in a mochitest
(or a number range if the number is not quite stable), but not the text
of the assertion.
On Thursday 2014-11-20 18:05 +0100, David Rajchenbach-Teller wrote:
I believe that we
L. David Baron writes:
On 20/11/14 17:56, Boris Zbarsky wrote:
Ah, we can't. We can whitelist the number of assertions in a mochitest
(or a number range if the number is not quite stable), but not the text
of the assertion.
On Thursday 2014-11-20 18:05 +0100, David Rajchenbach-Teller
There is a priority list of best to worst something like this:
1. Types
2. Compile time assertions
3. Unit tests
4. Fatal run time assertions
5. Non-fatal runtime assertions
6. Documentation
This is the order in which you are most likely to quickly find a
problem. Obviously 1 and 2 don't apply
7 matches
Mail list logo
