www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Improving unit tests

reply Janderson <ask me.com> writes:
 Someone who's a big unittesting fan should write up a proposal on
 this.  I think unittests are neat and all -- I probably don't use them
 as much as I should -- but I don't really know what's so great about
 named unittests or other things people mention that D's unittests
 lack.  I suspect Walter may be in the same boat.  You can't address a
 problem if you don't really understand it.
 --bb


Its funny, I was just thinking last night of starting a new thread about 
exactly that.  For me I only ever use unit tests in a simple way however 
I'd like to learn about move advanced features that D is missing.

I was originally thinking, maybe unit tests shouldn't be part of D to 
allow for innovation. However then I though, what about if D's unit 
tests where extensible though some language syntax?

Questions:
1) What features are missing from D's unit tests that you miss?

2) Should D decouple unittests from the language or should there be 
language changes to allow for for more extensible unit tests?

3) If you chose "more extensible unit tests" what language features 
would be needed to make this happen.

-Joel
Nov 07 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Janderson Wrote:


  > Someone who's a big unittesting fan should write up a proposal on
  > this.  I think unittests are neat and all -- I probably don't use them
  > as much as I should -- but I don't really know what's so great about
  > named unittests or other things people mention that D's unittests
  > lack.  I suspect Walter may be in the same boat.  You can't address a
  > problem if you don't really understand it.
  > --bb
 
 Its funny, I was just thinking last night of starting a new thread about 
 exactly that.  For me I only ever use unit tests in a simple way however 
 I'd like to learn about move advanced features that D is missing.
 
 I was originally thinking, maybe unit tests shouldn't be part of D to 
 allow for innovation. However then I though, what about if D's unit 
 tests where extensible though some language syntax?
 
 Questions:
 1) What features are missing from D's unit tests that you miss?


Named unit tests
Reporting individual failures and continuing. Note that you can recover from
module testing failures, but not from individual tests.
Compile-time unit tests, especially when making release builds.

 

 2) Should D decouple unittests from the language or should there be 
 language changes to allow for for more extensible unit tests?


I like having them built in.

 

 3) If you chose "more extensible unit tests" what language features 
 would be needed to make this happen.


I hope an author of one of the DUnit libraries answers this part.

 
 -Joel
Nov 07 2008
parent reply Gide Nwawudu <gide btinternet.com> writes:
On Fri, 07 Nov 2008 16:55:14 -0500, Jason House
<jason.james.house gmail.com> wrote:


Janderson Wrote:


  > Someone who's a big unittesting fan should write up a proposal on
  > this.  I think unittests are neat and all -- I probably don't use them
  > as much as I should -- but I don't really know what's so great about
  > named unittests or other things people mention that D's unittests
  > lack.  I suspect Walter may be in the same boat.  You can't address a
  > problem if you don't really understand it.
  > --bb
 
 Its funny, I was just thinking last night of starting a new thread about 
 exactly that.  For me I only ever use unit tests in a simple way however 
 I'd like to learn about move advanced features that D is missing.
 
 I was originally thinking, maybe unit tests shouldn't be part of D to 
 allow for innovation. However then I though, what about if D's unit 
 tests where extensible though some language syntax?
 
 Questions:
 1) What features are missing from D's unit tests that you miss?


Named unit tests
Reporting individual failures and continuing. Note that you can recover from
module testing failures, but not from individual tests.
Compile-time unit tests, especially when making release builds.


Nestable named unittest would be nice. If one group fails, report the
error and move onto the next.

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");
	    ...
	}		
}


 

 2) Should D decouple unittests from the language or should there be 
 language changes to allow for for more extensible unit tests?


I like having them built in.


Agreed


 

 3) If you chose "more extensible unit tests" what language features 
 would be needed to make this happen.


I hope an author of one of the DUnit libraries answers this part.

 
 -Joel




Gide
Nov 07 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Nov 7, 2008 at 6:56 PM, Gide Nwawudu <gide btinternet.com> wrote:

 Nestable named unittest would be nice. If one group fails, report the
 error and move onto the next.

 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");
            ...
        }
 }


_Nice_.
Nov 07 2008
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Gide Nwawudu" <gide btinternet.com> wrote in message 
news:i8k9h49nr5fk5l11qu8ujq5p42ck1kdmbd 4ax.com...

 On Fri, 07 Nov 2008 16:55:14 -0500, Jason House
 <jason.james.house gmail.com> wrote:


Janderson Wrote:


  > Someone who's a big unittesting fan should write up a proposal on
  > this.  I think unittests are neat and all -- I probably don't use 
 them
  > as much as I should -- but I don't really know what's so great about
  > named unittests or other things people mention that D's unittests
  > lack.  I suspect Walter may be in the same boat.  You can't address a
  > problem if you don't really understand it.
  > --bb

 Its funny, I was just thinking last night of starting a new thread about
 exactly that.  For me I only ever use unit tests in a simple way however
 I'd like to learn about move advanced features that D is missing.

 I was originally thinking, maybe unit tests shouldn't be part of D to
 allow for innovation. However then I though, what about if D's unit
 tests where extensible though some language syntax?

 Questions:
 1) What features are missing from D's unit tests that you miss?


Named unit tests
Reporting individual failures and continuing. Note that you can recover 
from module testing failures, but not from individual tests.
Compile-time unit tests, especially when making release builds.


 Nestable named unittest would be nice. If one group fails, report the
 error and move onto the next.


Last time I tried to use D's unittests, I had a ton of assert statements. On 
the first run one of them triggered, obviously halting execution, and I 
immediately said to myself "this is stupid" and set out writing a 
"NonFatalAssert()" utility function that displayed assertion failures to 
Stdout, incremented a "numFailures" counter (that's later queried at the 
beginning of main(), along with the flushing of Stdout), and continued 
onward.

So yes, I'd say the ability keep the tests going after one failure 
(preferably with descriptive names and grouping) is pretty important.


 2) Should D decouple unittests from the language or should there be
 language changes to allow for for more extensible unit tests?


I like having them built in.


 Agreed


Ditto
Nov 07 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Gide Nwawudu, el  7 de noviembre a las 23:56 me escribiste:

 On Fri, 07 Nov 2008 16:55:14 -0500, Jason House
 <jason.james.house gmail.com> wrote:
 

Janderson Wrote:


  > Someone who's a big unittesting fan should write up a proposal on
  > this.  I think unittests are neat and all -- I probably don't use them
  > as much as I should -- but I don't really know what's so great about
  > named unittests or other things people mention that D's unittests
  > lack.  I suspect Walter may be in the same boat.  You can't address a
  > problem if you don't really understand it.
  > --bb
 
 Its funny, I was just thinking last night of starting a new thread about 
 exactly that.  For me I only ever use unit tests in a simple way however 
 I'd like to learn about move advanced features that D is missing.
 
 I was originally thinking, maybe unit tests shouldn't be part of D to 
 allow for innovation. However then I though, what about if D's unit 
 tests where extensible though some language syntax?
 
 Questions:
 1) What features are missing from D's unit tests that you miss?


Named unit tests
Reporting individual failures and continuing. Note that you can recover from
module testing failures, but not from individual tests.
Compile-time unit tests, especially when making release builds.


 
 Nestable named unittest would be nice. If one group fails, report the
 error and move onto the next.


Also I think a "check" which only report errors but don't stop the current
test could be useful. Most unit testing frameworks provides that.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
The diference is simple: hackers build things, crackers break them.
Nov 11 2008
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 07 Nov 2008 08:25:04 -0800, Janderson wrote:


 I'd like to learn about move advanced features that D is missing.


The D language does *not* do unit testing. At best, it provides a place in
which the coder can put their unit testing code and an automated initiation
of the coder's unit test code.

 

 I was originally thinking, maybe unit tests shouldn't be part of D to 
 allow for innovation. However then I though, what about if D's unit 
 tests where extensible though some language syntax?
 
 Questions:
 1) What features are missing from D's unit tests that you miss?


** A variation of the assert statement that does not halt execution upon
finding an error. Instead, it just reports the error and moves on to the
next test.

** A method of identifying the failing test other than by file-name and
line-number. 

** A method by by the number of failures and successes are recorded and
reported at the end of execution. Possibly event made availble in symbolic
form to the coder for whatever purposes they choose. eg. Keeping a database
of unit ttest results over time.
 

 2) Should D decouple unittests from the language or should there be 
 language changes to allow for for more extensible unit tests?


Language changes. Uni testing outside of the language is already possible
by using the 'debug' or 'version' facilities, for examle.


 3) If you chose "more extensible unit tests" what language features 
 would be needed to make this happen.


In addition to those above...
** Being able to run unit tests on a per-module basis without the need of a
main() function.
** Being able to import and declare symbols so that they are only in scope
for their unit test block.
** Nesting of unit test blocks.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 07 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Nov 8, 2008 at 9:48 AM, Derek Parnell <derek psych.ward> wrote:

 On Fri, 07 Nov 2008 08:25:04 -0800, Janderson wrote:


 I'd like to learn about move advanced features that D is missing.


 The D language does *not* do unit testing. At best, it provides a place in
 which the coder can put their unit testing code and an automated initiation
 of the coder's unit test code.



 I was originally thinking, maybe unit tests shouldn't be part of D to
 allow for innovation. However then I though, what about if D's unit
 tests where extensible though some language syntax?

 Questions:
 1) What features are missing from D's unit tests that you miss?


 ** A variation of the assert statement that does not halt execution upon
 finding an error. Instead, it just reports the error and moves on to the
 next test.


Can't that be done by a library function?  I've seen in Python
unittesting the use of "assert_" instead of the built-in "assert".  I
assume it's for the same reason.


 ** A method of identifying the failing test other than by file-name and
 line-number.


Seems like a lib could do this too.
Just some sort of   BeginTests("Module identification") that's tied
into the definition of that assert_()


 ** A method by by the number of failures and successes are recorded and
 reported at the end of execution. Possibly event made availble in symbolic
 form to the coder for whatever purposes they choose. eg. Keeping a database
 of unit ttest results over time.


Can that be done with a lib?


 In addition to those above...
 ** Being able to run unit tests on a per-module basis without the need of a
 main() function.


Yeh, that one is annoying.  You shouldn't need to have a main to run
unit tests.  If there isn't one the compiler should supply an empty
one when unittesting.


 ** Being able to import and declare symbols so that they are only in scope
 for their unit test block.


Agreed.  version(UnitTests) { import module_for_tests; unittest { .. } }

Is annoying.  Being able to stick that import inside the unittest{ ...
} would be much nicer.


 ** Nesting of unit test blocks.


You mean nesting unittest{  unittest{ .. } ..} What would that be for?

But on the subject of nesting, I've noticed it's not possible to put
unittests _inside_ classes and structs.  Or inside functions to test
nested functions.  I guess there is a problem of supplying an
appropriate context there.  Not sure if it can be solved.  For classes
I think it would be ok if you just treat unittest{} like a static
method.

--bb
Nov 07 2008
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 8 Nov 2008 10:42:16 +0900, Bill Baxter wrote:


 On Sat, Nov 8, 2008 at 9:48 AM, Derek Parnell <derek psych.ward> wrote:



 ** A variation of the assert statement that does not halt execution upon
 finding an error. Instead, it just reports the error and moves on to the
 next test.


 
 Can't that be done by a library function? 


 ...


 Seems like a lib could do this too.


 ... 

 Can that be done with a lib?


Sure they can all be done via library functions. No problem with that. In
fact I have a test_equal() and test_true() functions that implement this
functionality.


 ** Nesting of unit test blocks.


 
 You mean nesting unittest{  unittest{ .. } ..} What would that be for?


In conjunction with variable declaration scope within unittest blocks.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 07 2008
parent ore-sama <spam here.lot> writes:
Derek Parnell Wrote:


 ** Nesting of unit test blocks.


 
 You mean nesting unittest{  unittest{ .. } ..} What would that be for?


 
 In conjunction with variable declaration scope within unittest blocks.


doesn't D have scope blocks?
Nov 08 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Sat, Nov 8, 2008 at 9:48 AM, Derek Parnell <derek psych.ward> wrote:

 On Fri, 07 Nov 2008 08:25:04 -0800, Janderson wrote:


 I'd like to learn about move advanced features that D is missing.


 The D language does *not* do unit testing. At best, it provides a place in
 which the coder can put their unit testing code and an automated initiation
 of the coder's unit test code.



 I was originally thinking, maybe unit tests shouldn't be part of D to
 allow for innovation. However then I though, what about if D's unit
 tests where extensible though some language syntax?

 Questions:
 1) What features are missing from D's unit tests that you miss?


 ** A variation of the assert statement that does not halt execution upon
 finding an error. Instead, it just reports the error and moves on to the
 next test.


 
 Can't that be done by a library function?  I've seen in Python
 unittesting the use of "assert_" instead of the built-in "assert".  I
 assume it's for the same reason.
 

 ** A method of identifying the failing test other than by file-name and
 line-number.


 
 Seems like a lib could do this too.
 Just some sort of   BeginTests("Module identification") that's tied
 into the definition of that assert_()
 

 ** A method by by the number of failures and successes are recorded and
 reported at the end of execution. Possibly event made availble in symbolic
 form to the coder for whatever purposes they choose. eg. Keeping a database
 of unit ttest results over time.


 
 Can that be done with a lib?


I agree with the spirit that we need to look more into what we can do 
with libraries. At this stage in D's development, this group is a 
crucible of new language features, which is good, but oughtn't deter us 
from looking at libraries.


 In addition to those above...
 ** Being able to run unit tests on a per-module basis without the need of a
 main() function.


 
 Yeh, that one is annoying.  You shouldn't need to have a main to run
 unit tests.  If there isn't one the compiler should supply an empty
 one when unittesting.


At a point I'd added --main to rdmd. It defines a vacuous void main(){} 
to the banana. (I removed it since because I thought it's too minor a 
feature.) When I talked to Walter about that, he said he'd consider 
adding such a switch to dmd.


 ** Being able to import and declare symbols so that they are only in scope
 for their unit test block.


 
 Agreed.  version(UnitTests) { import module_for_tests; unittest { .. } }

 Is annoying.  Being able to stick that import inside the unittest{ ...
 } would be much nicer.


For a good time, try version(unittest). Yours truly's brainchild :o).


 ** Nesting of unit test blocks.


 
 You mean nesting unittest{  unittest{ .. } ..} What would that be for?
 
 But on the subject of nesting, I've noticed it's not possible to put
 unittests _inside_ classes and structs.  Or inside functions to test
 nested functions.  I guess there is a problem of supplying an
 appropriate context there.  Not sure if it can be solved.  For classes
 I think it would be ok if you just treat unittest{} like a static
 method.


I agree these should be added to the language, and indeed as static 
blocks. Moreover, unittest should in fact be put inside functions too 
and treated as a "run-once" block. But maybe that goes a bit too far :o).


Andrei
Nov 07 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 unittest should in fact be put inside functions too


I agree.

Bye,
bearophile
Nov 09 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Janderson wrote:

 Questions:
 1) What features are missing from D's unit tests that you miss?


- Named tests
- Error reporting
- The ability to list unit tests
- The ability to get different types of output
- Continuous integration support
- Running a subset of the tests
- Not running main after running tests
- Not running tests before main, and not having to recompile to get this 
behavior
- A setup/teardown structure with common code to be run before and after 
a particular set of tests. This one won't happen without a major 
redesign of the builtin unittests, though.

Of those, Dunit has named tests and good error reporting. It has 
continuous integration support. It can list tests without running them. 
I'm adding support for running particular subsets with the default test 
runner right now (test runners can do this, but there's no command line 
argument to support it). And of course it has setup/teardown methods.

Dunit replaces main, so main doesn't run after it, and it doesn't run 
before main.


 2) Should D decouple unittests from the language or should there be 
 language changes to allow for for more extensible unit tests?


D should decouple unittests from the runtime.


 3) If you chose "more extensible unit tests" what language features 
 would be needed to make this happen.


1. Named unittests.
There are a few reasons for this:
	- Your code should be self-documenting. unittest {} tells you nothing.
	- If a test fails, you want to know which test it is. A backtrace 
library helps more than a unittest name, I admit, but both are useful.
	- Naming for unittests integrates better with continuous integration 
servers like CruiseControl and CCNET -- these expect unittests to have 
fully qualified names.

2. A pluggable unittest runner.
With this, any functionality that unittests lack can be provided. The 
unittest runner has to be in the runtime, of course.

3. Each test should be its own function.
Currently, all unittest blocks in any module are conglomerated into one 
function, ModuleInfo.unitTest. ModuleInfo should have a list of 
name/function pairs. This is required for named unittests, and for 
reporting errors on a per-test basis.

4. The unittest runner must be able to have runtime arguments.
At work, we use test-driven development. We have about 5700 classes, 
half of which are test classes. That's 7,200 tests currently. They take 
ten minutes to run. You can't do TDD with ten minute lag for running tests.

Command line arguments are the easiest way of changing options at 
runtime. The alternatives are some sort of interactive session with 
stdio, an options file, or recompiling (which isn't runtime). None of 
these is particularly good.
Nov 07 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Christopher Wright wrote:

 I'm adding support for running particular subsets with the default test 
 runner right now (test runners can do this, but there's no command line 
 argument to support it).


Dunit now supports this.
Nov 08 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Christopher Wright wrote:

 Janderson wrote:
 

 3) If you chose "more extensible unit tests" what language features 
 would be needed to make this happen.


 
 1. Named unittests.
 There are a few reasons for this:
     - Your code should be self-documenting. unittest {} tells you nothing.
     - If a test fails, you want to know which test it is. A backtrace 
 library helps more than a unittest name, I admit, but both are useful.
     - Naming for unittests integrates better with continuous integration 
 servers like CruiseControl and CCNET -- these expect unittests to have 
 fully qualified names.


I agree that this would be nice.  Perhaps unittest("name") for the syntax?


 2. A pluggable unittest runner.
 With this, any functionality that unittests lack can be provided. The 
 unittest runner has to be in the runtime, of course.


There's one in druntime.


 3. Each test should be its own function.
 Currently, all unittest blocks in any module are conglomerated into one 
 function, ModuleInfo.unitTest. ModuleInfo should have a list of 
 name/function pairs. This is required for named unittests, and for 
 reporting errors on a per-test basis.


This would be nice as well.  Recovering from unit tests currently skips 
all tests in a module after the test that failed, which isn't terribly 
desirable.


 4. The unittest runner must be able to have runtime arguments.
 At work, we use test-driven development. We have about 5700 classes, 
 half of which are test classes. That's 7,200 tests currently. They take 
 ten minutes to run. You can't do TDD with ten minute lag for running tests.
 
 Command line arguments are the easiest way of changing options at 
 runtime. The alternatives are some sort of interactive session with 
 stdio, an options file, or recompiling (which isn't runtime). None of 
 these is particularly good.


Hm... perhaps if argc/argv were passed to the unit test runner from the 
runtime?  This would leave the choice of switches up to the user.


Sean
Nov 08 2008
parent reply Don <nospam nospam.com> writes:
Sean Kelly wrote:

 Christopher Wright wrote:

 Janderson wrote:


 3) If you chose "more extensible unit tests" what language features 
 would be needed to make this happen.


 1. Named unittests.
 There are a few reasons for this:
     - Your code should be self-documenting. unittest {} tells you 
 nothing.
     - If a test fails, you want to know which test it is. A backtrace 
 library helps more than a unittest name, I admit, but both are useful.
     - Naming for unittests integrates better with continuous 
 integration servers like CruiseControl and CCNET -- these expect 
 unittests to have fully qualified names.


 
 I agree that this would be nice.  Perhaps unittest("name") for the syntax?
 

 2. A pluggable unittest runner.
 With this, any functionality that unittests lack can be provided. The 
 unittest runner has to be in the runtime, of course.


 
 There's one in druntime.
 

 3. Each test should be its own function.
 Currently, all unittest blocks in any module are conglomerated into 
 one function, ModuleInfo.unitTest. ModuleInfo should have a list of 
 name/function pairs. This is required for named unittests, and for 
 reporting errors on a per-test basis.


 
 This would be nice as well.  Recovering from unit tests currently skips 
 all tests in a module after the test that failed, which isn't terribly 
 desirable.


Couldn't there be some hidden global bool, isInUnitTest, which is set 
when the unit tests start to run, and which is set back to false when 
the last one ends. assert() could have different behaviour depending on 
whether it's in the unit testing phase, or not.
Nov 08 2008
next sibling parent Janderson <ask me.com> writes:
Don wrote:

 assert() could have different behaviour depending on 
 whether it's in the unit testing phase, or not.


I agree.  I also think that you may want different types of asserts such as:

assert() //Standard

unitchecked_assert( ) //Only happens for unit checks.  I've found this 
very useful in my projects.

soft_assert( ) //Doesn't stop program function but reports error.  Users 
can of course override this to send the output elsewhere.  It can also 
be turned on for verbose check where it will stop in the debugger when 
it occurs.  Also this would not show up in unit checks.  Why? Because 
the unit checks should be able to pass invalid data into functions (ie a 
missing file name) and have the program continue.  Note softasserts are 
similar but not the same as exceptions.
Nov 09 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Don wrote:

 Sean Kelly wrote:

 Christopher Wright wrote:

 3. Each test should be its own function.
 Currently, all unittest blocks in any module are conglomerated into 
 one function, ModuleInfo.unitTest. ModuleInfo should have a list of 
 name/function pairs. This is required for named unittests, and for 
 reporting errors on a per-test basis.


 This would be nice as well.  Recovering from unit tests currently 
 skips all tests in a module after the test that failed, which isn't 
 terribly desirable.


 
 Couldn't there be some hidden global bool, isInUnitTest, which is set 
 when the unit tests start to run, and which is set back to false when 
 the last one ends. assert() could have different behaviour depending on 
 whether it's in the unit testing phase, or not.


druntime has pluggable unit test runners, so that's entirely possible. 
You couldn't call that function assert, though.

On the other hand, you might find crashing in these situations if assert 
doesn't abort the current test:

unittest
{
	int[] array = getArray();
	assert (array.length == 1);
	assert (array[0] == something); // array bounds error? wtf?
}

So that's not a good idea.
Nov 09 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Don wrote:

 
 Couldn't there be some hidden global bool, isInUnitTest, which is set 
 when the unit tests start to run, and which is set back to false when 
 the last one ends. assert() could have different behaviour depending on 
 whether it's in the unit testing phase, or not.


assert currently must throw when using DMD because it doesn't generate a 
fukk stack frame for the call.  For unit tests though, a unit tester 
could override assert only for the duration of unit testing.


Sean
Nov 09 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Don wrote:

 Couldn't there be some hidden global bool, isInUnitTest, which is set 
 when the unit tests start to run, and which is set back to false when 
 the last one ends. assert() could have different behaviour depending 
 on whether it's in the unit testing phase, or not.


 
 assert currently must throw when using DMD because it doesn't generate a 
 fukk stack frame for the call.


I see that annoys the heck out of you :o).

Andrei
Nov 09 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 Sean Kelly wrote:

 Don wrote:

 Couldn't there be some hidden global bool, isInUnitTest, which is set 
 when the unit tests start to run, and which is set back to false when 
 the last one ends. assert() could have different behaviour depending 
 on whether it's in the unit testing phase, or not.


 assert currently must throw when using DMD because it doesn't generate 
 a fukk stack frame for the call.


 
 I see that annoys the heck out of you :o).


Oops.  that's what I get for typing that with only one hand and one eye 
on the computer :-)


Sean
Nov 09 2008