Re: dunit r247
Christopher Wright:
Having other testing frameworks/tools for D is good. There are many kinds of
testing, and the built-in one isn't supposed to implement them all.
Regarding the issues of unit testing with unittest{}, I think the built-in
unittesting has to be improved, to removed some of such issues. I am not
looking for an universal and perfect built-in unittesting, and I think the
built-in unittesting has to be kept simple, but the following things have to be
fixed, maybe Walter will eventually understand why they are important:
- Unittests are not labeled.
- There is no output that specifically indicates that the tests were run.
- A failing test will prevent any other tests from running.
- There is no indication of which test failed, if any.
Such things are bare-bone functionality for any unit testing system.
And I'd like to add a way to unittest at compile time too, to test types,
templates, etc. (Until few weeks ago I didn't know any way at all to do this,
then someone has given me a hint).
What's the advantage of:
expect(foo(5), equals(3) | greaterThan(5));
Compared to:
expect(foo(5) == 3 | foo(5) 5);
Or:
auto aux5 = foo(5);
expect(aux5 == 3 | aux5 5);
?
If you write Dunit tests in separate modules, while your production code
doesn't include dunit, you cannot test private methods. Dunit encourages the
practice of separating tests and modules.
For me it's often better to keep tests very close to the things they test. It
helps me spot and fix bugs faster, to avoid jumping across files, and when I
quickly move a block of code (function, class, template, etc) when I reorganize
the code it is less likely for me to lose its tests along the way. I think
tests are a part of a function/class/template, just like its ddocs.
Bye,
bearophile
Re: dunit r247
On Thu, 19 Mar 2009 11:34:52 -0400, bearophile
bearophileh...@lycos.com wrote:
Christopher Wright:
Having other testing frameworks/tools for D is good. There are many kinds of
testing, and the built-in one isn't supposed to implement them all.
Regarding the issues of unit testing with unittest{}, I think the built-in
unittesting has to be improved, to removed some of such issues. I am not
looking for an universal and perfect built-in unittesting, and I think the
built-in unittesting has to be kept simple, but the following things have to
be fixed, maybe Walter will eventually understand why they are important:
- Unittests are not labeled.
- There is no output that specifically indicates that the tests were run.
- A failing test will prevent any other tests from running.
- There is no indication of which test failed, if any.
Such things are bare-bone functionality for any unit testing system.
And I'd like to add a way to unittest at compile time too, to test types,
templates, etc. (Until few weeks ago I didn't know any way at all to do this,
then someone has given me a hint).
I think that nestable named unittest would be nice. I'll raise it as
an enhancement request.
unittest (XML) {
unittest(elements) {
assert(isValidXml(aaa /));
assert(isValidXml(aaa/));
assert(isValidXml(aaa/aaa));
...
}
unittest(attributes) {
assert(isValidXml(aaa abc=\x\/));
assert(isValidXml(aaa abc=\x\ def=\y\/));
...
}
unittest(encoding) {
assert(encode(hello) is hello);
assert(encode(a b) == a gt; b);
...
}
}
Gide
Re: dunit r247
On Thu, 19 Mar 2009 18:26:32 +, Gide Nwawudu g...@btinternet.com
wrote:
On Thu, 19 Mar 2009 11:34:52 -0400, bearophile
bearophileh...@lycos.com wrote:
Christopher Wright:
Having other testing frameworks/tools for D is good. There are many kinds of
testing, and the built-in one isn't supposed to implement them all.
Regarding the issues of unit testing with unittest{}, I think the built-in
unittesting has to be improved, to removed some of such issues. I am not
looking for an universal and perfect built-in unittesting, and I think the
built-in unittesting has to be kept simple, but the following things have to
be fixed, maybe Walter will eventually understand why they are important:
- Unittests are not labeled.
- There is no output that specifically indicates that the tests were run.
- A failing test will prevent any other tests from running.
- There is no indication of which test failed, if any.
Such things are bare-bone functionality for any unit testing system.
And I'd like to add a way to unittest at compile time too, to test types,
templates, etc. (Until few weeks ago I didn't know any way at all to do this,
then someone has given me a hint).
I think that nestable named unittest would be nice. I'll raise it as
an enhancement request.
Added http://d.puremagic.com/issues/show_bug.cgi?id=2749
Gide
Re: dunit r247
bearophile wrote:
Christopher Wright:
Having other testing frameworks/tools for D is good. There are many kinds of
testing, and the built-in one isn't supposed to implement them all.
Regarding the issues of unit testing with unittest{}, I think the built-in
unittesting has to be improved, to removed some of such issues. I am not
looking for an universal and perfect built-in unittesting, and I think the
built-in unittesting has to be kept simple, but the following things have to be
fixed, maybe Walter will eventually understand why they are important:
- Unittests are not labeled.
- There is no output that specifically indicates that the tests were run.
- A failing test will prevent any other tests from running.
- There is no indication of which test failed, if any.
Such things are bare-bone functionality for any unit testing system.
And I'd like to add a way to unittest at compile time too, to test types,
templates, etc. (Until few weeks ago I didn't know any way at all to do this,
then someone has given me a hint).
What are you using for this? __traits(compiles) works for d2, to an
extent, and for d1, is (typeof(expression)). But for templates that have
to be mixed into some context, that's more tricky.
What's the advantage of:
expect(foo(5), equals(3) | greaterThan(5));
Compared to:
expect(foo(5) == 3 | foo(5) 5);
What error message should that give?
The former gives:
Expected: equal to 3 or greater than 5
But was: whatever value foo(5) returned
The latter gives:
Assertion error
If you write Dunit tests in separate modules, while your production code doesn't
include dunit, you cannot test private methods. Dunit encourages the practice of
separating tests and modules.
For me it's often better to keep tests very close to the things they test. It
helps me spot and fix bugs faster, to avoid jumping across files, and when I
quickly move a block of code (function, class, template, etc) when I reorganize
the code it is less likely for me to lose its tests along the way. I think
tests are a part of a function/class/template, just like its ddocs.
I believe that there is a benefit to keeping the tests close to the
tested code. I have not noticed a significant lack, however, when using
junit or nunit.
Bye,
bearophile
Re: dunit r247
bearophile wrote: For me it's often better to keep tests very close to the things they test. It helps me spot and fix bugs faster, to avoid jumping across files, and when I quickly move a block of code (function, class, template, etc) when I reorganize the code it is less likely for me to lose its tests along the way. I think tests are a part of a function/class/template, just like its ddocs. Well, you can always put the Dunit tests in the same module; this was just a suggestion.
Re: dunit r247
Christopher Wright dhase...@gmail.com wrote in message
news:gpuibc$1nr...@digitalmars.com...
bearophile wrote:
What's the advantage of:
expect(foo(5), equals(3) | greaterThan(5));
Compared to:
expect(foo(5) == 3 | foo(5) 5);
What error message should that give?
The former gives:
Expected: equal to 3 or greater than 5
But was: whatever value foo(5) returned
The latter gives:
Assertion error
The nice thing about D is how often it lets you, as I prefer to word it,
Eat your cake and then still have it.
Attached is the assert-alternative that I use (D1/Tango). It's used like
this:
-
module nonFatalAssertTest.main;
import semitwist.util.nonFatalAssert;
void main()
{
FatalizeAsserts();
// Main program code here
}
unittest
{
int foo = 2;
// *REALLY* need a way for a template to automatically get
// the file/line of instantiation.
// Improvement to mixin syntax would also be nice
// Also, my editor doesn't know that backticks indicate a string,
// so it's still properly highlighted as code :)
mixin(NonFatalAssert!(__LINE__, __FILE__, `foo == 3 || foo 5`, foo is
bad));
mixin(NonFatalAssert!(__LINE__, __FILE__, `2 + 2 == 4`, Basic
arithmetic));
mixin(NonFatalAssert!(__LINE__, __FILE__, `false`));
}
-
Output of that is:
-
nonFatalAssertTest\main.d(16): Assert Failure (foo == 3 || foo 5): foo is
bad
nonFatalAssertTest\main.d(18): Assert Failure (false)
tango.core.exception.assertexcept...@semitwist\util\nonfatalassert.d(62): 2
Assert Failures
-
Granted, this doesn't currently output foo's actual value, but it probably
wouldn't be too hard to modify it to do so via std.algorithm-style trickery.
begin 666 nonFatalAssert.d
m...@4v5m:51W:7-T($QI8G)AGD-B\O(%=R:71T96X@:6...@=AE($0@')O
M9W)A;6UI;F@;%N9W5A9V4N#0H-B\J*B -D%U=AOCH-B0H5T5('=W
M=RYS96UI='=IW0N8V]M+!.:6-K(%-A8F%L875S:WDI#0H-D-O;G-I95R
M('1H:7,@=\...@8f4@=6YD97(@=AE('IL:6(@;EC96YS92X-BHO#0H-FUO
M9'5L92!S96UI='=IW0N=71I;YN;VY871A;$%SV5R=#L-@T*:6UP;W)T
M('1A;F=O+FEO+E-T9]U=#L-FEM]R=!T86YG;RYU=EL+D-O;G9EG0[
M#0H-b...@t*4v]u;F1S(QI:v...@82!c;VYTF%D:6-T:6]N(]F('1EFUS
M+!b...@=AIR!IR!J=7-T#0II;G1E;F1E9!T;R!A;QO=R!U;FET=5S
M=',@=\@;W5T'5T($%,3!F86EL=7)ER!I;G-T96%D#0IO9B!O;FQY(]U
M='!U='1I;F@=AE(9IG-T(]N92!A;f...@=AE;B!S=]PEN9RX-BHO
M#0HO+R J4D5!3$Q9*B!N965D($...@=v%y('1O(=E=!F:6QE+VQI;F4@;V8@
M=5MQA=4GR!I;G-T86YT:6%T:6]N#0IT96UP;%T92!.;VY871A;$%S
MV5R=AL;VYG(QI;F4L(-H87);72!F:6QE+!C:%r...@8v]n9p...@8vaa
MEM=(US9STB(BD-GL-@EC;VYS=!C:%r...@3f]n1f%t86q!W-EG0@
M/0T*2)[7x...@t*2)B;V]L(%].;VY871A;$%SV5R=%]R97-U;'0@/2 B
M?F-O;F1^(CM;B)^#0H)(E].;VY871A;$%SV5R=$H(GYL:6YE+G-TFEN
M9V]F?B(L()^9FEL92YS=')I;F=O9GXB+ B?F-O;F0NW1R:6YG;V9^(BP@
M(GYMVNW1R:6YG;V9^(BDH7TYO;D9A=%L07-S97)T7W)EW5L=D[(GX-
M@DB?2([#0H)+R]PF%G;6$H;7-G+ B3F]N1F%T86Q!W-EG0Z()^3F]N
M1F%T86Q!W-EG0I.PT*?0T*#0IT96UP;%T92!?3F]N1F%T86Q!W-EG0H
M;]N9R!L:6YE+!C:%r...@9fel92p@8VAAEM=(-O;F0L(-H87);72!M
MV](B(I#0I[#0H)8F]O;!?3F]N1F%T86Q!W-EG0H8F]O;!R97-U;'0I
M#0H)PT*0e...@aF5S=6QT*0T*0E[#0H)0EN;VY871A;$%SV5R=$-O
M=6YT*RL[#0H)0E3=1O=70N9F]R;6%T;XH(GM]*'m]...@07-s97)T($9A
M:6QUf...@*'M]*7M](BP-@D)2 @( @( @( @( @(!F:6QE+!L:6YE
M+!C;VYD+ T*0D)0D)( @(US9ST](B(@/R B(B Z((Z((@?B!MVI
M.PT*0E]#0H)0T*0ER971UFX@F5S=6QT.PT*7T-GT-G!R:79A=4@
M=6EN=!N;VY871A;$%SV5R=$-O=6YT/3 [#0IU:6YT(=E=$YO;D9A=%L
M07-S97)T0V]U;G0H*0T*PT*7)E='5R;B!N;VY871A;$%SV5R=$-O=6YT
M.PT*?0T*=F]I9!R97-E=$YO;D9A=%L07-S97)T0V]U;G0H*0T*PT*6YO
M;D9A=%L07-S97)T0V]U;G0@/2 P.PT*?0T*#0IV;VED($9A=%L:7IE07-S
M97)Tr...@i#0i[#0h):68H9V5T3F]N1F%T86Q!W-EG1#;W5N=@I(#X@,D-
M@E[#0H)5-T9]U=YF;'5S:@I.PT*0EAW-EG0H9F%LV4L#0H)0ET
M;R$H8VAAEM=*2AG971.;VY871A;$%SV5R=$-O=6YT*DI('X-@D)2(@
M07-S97)T($9A:6QUF4B('X-@D)2AG971.;VY871A;$%SV5R=$-O=6YT
B*D@/3T@,2 _((B(#H@(G,B*0T*0DI.PT*7T-GT-@``
`
end
Re: dunit r247
Christopher Wright wrote: bearophile wrote: What's the advantage of: expect(foo(5), equals(3) | greaterThan(5)); Compared to: expect(foo(5) == 3 | foo(5) 5); What error message should that give? The former gives: Expected: equal to 3 or greater than 5 But was: whatever value foo(5) returned The latter gives: Assertion error What about this syntax? check!(% == 3 || % == 5)(foo(5)); This could display: Expected: (% == 3 || % == 5) for value of foo(5). Then you don't have to dick about writing classes when you want to test something. Rule one of a good API: get out of my way. :D -- Daniel
