'live' testing style

[spir]

On 02/15/2011 02:42 AM, Jonathan M Davis wrote:
> On Monday, February 14, 2011 17:26:26 Don wrote:
>> Jonathan M Davis wrote:
>>> On Monday, February 14, 2011 12:49:11 Tomek Sowiński wrote:
>>>> spir napisał:
>>>>> * Why isn't testList a unittest block?
>>>>>
>>>>> Using named funcs, I can switch on&  off specific test suites by
>>>>> (un)commenting their call from the main and unique unittest block.
>>>>> Else, either they all run, or none. During development, I only keep
>>>>> active the test func(s) relative to the feature I'm currently working
>>>>> on. Remedy: named unittests.
>>>>
>>>> The interesting thing about named unit tests is that their names aren't
>>>> interesting at all. They are usually dull and forced; testing filterFoo
>>>> will be called testFilterFoo, etc. Their only purpose is to suppress
>>>> running of unrelated tests.
>>>>
>>>>
>>>> Now, there is a seemingly unrelated proposal to include every ddoc'ed
>>>> unit test in the preceding declaration as an example. This is great
>>>> because it implies ownership -- a unit test is 'owned' by the symbol
>>>> above. Going further, it can also be named after its owner.
>>>>
>>>> module ooh;
>>>>
>>>> void foo();
>>>>
>>>> unittest { test foo... }
>>>>
>>>> Compiling with --unittest=ooh.foo runs this unittest only. Nested
>>>> control as a bonus: compiling with --unittest=ooh runs only the tests
>>>> in module ooh.
>>>>
>>>> So there you go, named unit tests without naming.
>>>
>>> The number one reason that I want named unit tests is stack traces.
>>> unittest428 or whatever a unittest block gets named to is pretty
>>> useless. So, while an assert within the unit test is fine, since it
>>> gives a file and line number which is in the unittest block, exceptions
>>> thrown from stuff called by the unit test become hard to track down,
>>> since you don't know which unit test was being run.
>>
>> Sounds as though a solution would be to have unittests automatically
>> named as "_unittest" ~ __LINE__
>> rather than an arbitrary integer.
>> Wouldn't work in the case where there are two unittests on the same line:
>> unittest { assert(true); } unittest { assert(true); }
>> But we can deal with that.
>
> I still think that having named unit tests is something that we should do at
> some point (and it would be nicely backwards compatible), but naming the unit
> test function after the line number that it's on would already be a big
> improvement.
>
> I have no idea how they're named/numbered now. I haven't been able to discern
> any obvious pattern, and with a module like std.datetime, which has lots of
> unittest blocks, even if it were clearly unittest1, unittest2, unittest3, etc.
> it would still be quite hard to figure out which unittest block was running when
> the exception threw, since you'd have to count them all.
>
> Using __LINE__ would be a big improvement - though unless we figure out some way
> of advertising that, most people probably wouldn't have a clue, and it wouldn't
> help them much. It would definitely be a positive change though.
>
> And since if someone is bizarre enough to put more than one unittest block on
> one line, well then they suffer for what is almost certainly a poor choice. But
> it would still narrow it down for them.

The only /meaningful/ choice for a programmer, in the general case, is 
programmer-chosen names. Don't you think? One can then even nicely use those 
names like eg "see example use in unittest ApplicationToArithmetics".
If people are happy with naming unittests using ordinals (1 2 3...) or line 
numbers (in realease), well... let them free, after all it's their choice :-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com