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 a
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 able to do that when initially landing the ass
On Friday 2014-11-21 16:32 +, Gijs Kruitbosch wrote:
> On 20/11/2014 17:14, L. David Baron wrote:
> >>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
On 20/11/2014 17:14, L. David Baron wrote:
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 Rajchen
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:
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 to
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 Rajchenba
> 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 th
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 11/20/14, 11:51 AM, David Rajchenbach-Teller wrote:
I wasn't aware that we could whitelist an individual NS_ASSERTION. How
do we do that?
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 a
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.
> Assum
On 11/20/14, 10:38 AM, David Rajchenbach-Teller wrote:
I have put together an API that could replace runtime warnings with
something much more actionable, and much less noisy. They key aspects
are that:
- when the code is executed as part of the test suite, it causes test
failures;
- individual t
blog:
http://yoric.rajtel.name/2014/11/20/rfc-we-deserve-better-than-runtime-warnings/
Feedback would be appreciated.
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
__
13 matches
Mail list logo
