'live' testing style

[spir]

On 02/14/2011 09:49 PM, 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.

I have thought at something similar (alse after the related thread about ddoc), 
but let it down for various reasons:

* Completely implicit. In particular, one cannot learn the feature by reading 
other people's code; actually, one cannot even guess there is a feature there...
* Imposed placement, order. Sometimes, placing the unittest immediately after 
what it test is not the best. Sometimes, one wants to group part ot all 
unittests. Sometimes, there are tests relative several funcs / types, etdc.
* What about several unittests for a given feature. They would all run, or only 
the first one, or what?
* Naming is a clue for the reader. Esp when there are several tests, or when 
the test check a particular point.
* Possible extension: params. (I thinkin particular at benchmarks, for 
instance, but there would certainly be numerous other cases, including getting 
args such as data file names from the command line.)
	unittest testScan (string filename) { ... }
or even
	unittest testScan (string source, string result) { ... }
[Well, actually, i'm not fan of such an extension, prefere to keep things 
simple, and it's already trivial to factor out a piece of test.]

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