"Bill Baxter" wrote in message
news:mailman.64.1252768975.20261.digitalmar...@puremagic.com...
> On Sat, Sep 12, 2009 at 7:09 AM, Justin Johansson
> wrote:
>> Lutger Wrote:
>>
>>> I'm rewriting my testing stuff at the moment, I hoped to use the runtime
>>> features to be able to user regular ass
Lutger Wrote:
> Justin Johansson wrote:
> ...
> > If I haven't misread you, sounds we are on the same track.
>
> For sure, one thing I have come to appreciate is how Walter made things so
> simple: one file containing related code, documentation and the testsuite.
> As soon as you have more tha
On Sat, Sep 12, 2009 at 7:09 AM, Justin Johansson
wrote:
> Lutger Wrote:
>
>> I'm rewriting my testing stuff at the moment, I hoped to use the runtime
>> features to be able to user regular asserts too but that didn't work out.
>>
>> Do you know you can get rid of the need to pass __FILE__ and __L
Justin Johansson wrote:
...
> If I haven't misread you, sounds we are on the same track.
For sure, one thing I have come to appreciate is how Walter made things so
simple: one file containing related code, documentation and the testsuite.
As soon as you have more than one of anything there is bo
Lutger Wrote:
> I'm rewriting my testing stuff at the moment, I hoped to use the runtime
> features to be able to user regular asserts too but that didn't work out.
>
> Do you know you can get rid of the need to pass __FILE__ and __LINE__?
>
> Define the functions this way:
>
> void expectEqua
I'm rewriting my testing stuff at the moment, I hoped to use the runtime
features to be able to user regular asserts too but that didn't work out.
Do you know you can get rid of the need to pass __FILE__ and __LINE__?
Define the functions this way:
void expectEquals(T)(T some_x, T some_y,
"Nick Sabalausky" wrote in message
news:h8f6pg$1q5...@digitalmars.com...
> "Justin Johansson" wrote in message
> news:h8edsq$b9...@digitalmars.com...
>>
>> The idea is to keep working within D's built in unit test facility; just
>> don't use assert statements in current fashion as if one fails
"Justin Johansson" wrote in message
news:h8edsq$b9...@digitalmars.com...
>
> The idea is to keep working within D's built in unit test facility; just
> don't use assert statements in current fashion as if one fails then whole
> test stops running.
I found that to be an enormous PITA too...
>
Justin Johansson wrote:
Hope it doesn't sound like I just discovered America but being a D newbie one
is keen to play with all the language features. So soon getting round to
playing with D's unit test facility with JUnit (Java test unit) experience in
mind, found that I wanted all my tests
Hope it doesn't sound like I just discovered America but being a D newbie one
is keen to play with all the language features. So soon getting round to
playing with D's unit test facility with JUnit (Java test unit) experience in
mind, found that I wanted all my tests to run even if one or the
10 matches
Mail list logo
