On Tue, May 4, 2010 at 3:11 AM, Andrei Alexandrescu <[email protected]> wrote: > Walter Bright wrote: >> >> >> Andrei Alexandrescu wrote: >>> >>> Walter Bright wrote: >>>> >>>> >>>> Andrei Alexandrescu wrote: >>>>> >>>>> Since we've been looking into this now and we have a solution in our >>>>> collective mental caches, is there please a chance to effect this change >>>>> for >>>>> this beta? I'm telling you, it is an _important_ step forward in >>>>> unittesting >>>>> D programs. >>>>> >>>> >>>> One thing I should mention is that dmd now calls a different function >>>> for unittest asserts than the asserts normally do, and it does not regard >>>> those calls as "terminating" calls. This means that the unittest behavior >>>> can now be controlled by adjusting the runtime library, without affecting >>>> the assert failure code. >>> >>> In light of Sean's latest discovery, I'm afraid there's an issue here. >>> The asserts are only replaced syntactically at top-level unittests. My >>> understanding was that there was a "unittest stage" global that dictates how >>> assertion failures are handled, regardless of origin. >>> >>> I'm unclear on what the best policy is. Experience suggests that flat == >>> bad. >>> >> >> I'm reluctant to transform all asserts because: >> >> 1. this means all asserts, whether meant for unit testing or not, have to >> have return code, negatively affecting optimization all the time > > This sounds like latching onto an implementation artifact. The way I'm > seeing things is: > > bool g_runningUnittests; > > // C entry point > int _main() { > g_runningUnittests = true; > __runUnittests(); > g_runningUnittests = false; > d_main(); > } > > The implementation of assertFailed() consults g_runningUnittests. And that's > all there is to it. > >> 2. many asserts are not meant at all to be unit tests, and there's no >> reason to think otherwise when they are outside the unittest block > > I guess but I have the feeling you are taking a couple of wrong turns that > reflect lack of experience with unittests. > > 1. A failing unittest only prints and continues > > 2. Top-level asserts are different from other asserts > > I'm not claiming to be an expert in unittesting but from what I know from > other unittest facilities, I believe the following is the correct behavior: > > 1. A failing unittest means that particular unittest is terminated > immediately and counted as "failed" exactly once. A failed unittest has an > identity, you can't say "this unittest has failed 3 times in the following > places". > > 2. unittest-level assert and any-level assert are the same deal. It's basic > (de)composability and what anyone expects since the invention of the stack. > > Please let's not introduce odd behavior unless we're based on something. > > > Andrei > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals >
What's wrong with automatically wrapping unittests with try/catch block? Why is the "bool g_runningUnittests;" even necessary? Anyway, I believe top-level unittest assert behavior shouldn't differ from other asserts. _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
