Why think unit tests should be in their own source code hierarchy instead of side-by-side

Seb seb at wilzba.ch
Thu Mar 22 13:14:02 UTC 2018


On Thursday, 22 March 2018 at 12:25:59 UTC, bauss wrote:
> On Thursday, 22 March 2018 at 11:47:34 UTC, Alexandru Ermicioi 
> wrote:
>> On Thursday, 22 March 2018 at 11:19:46 UTC, Basile B. wrote:
>>> On Thursday, 22 March 2018 at 11:00:31 UTC, Atila Neves wrote:
>>>> On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves 
>>>> wrote:
>>>>> [...]
>>>>
>>>> Direct link:
>>>>
>>>> https://atilanevesoncode.wordpress.com/2018/03/22/keep-d-unittests-separated-from-production-code/
>>>>
>>>> Sorry for the forum spam.
>>>>
>>>> Atila
>>>
>>> I don't agree at all. Everything is so much faster when 
>>> unittest blocks are in the same module as the stuff that are 
>>> tested. Generally i think that it makes things easier.
>>
>> It's easier, true. But not all code can be nicely unittested 
>> using small chunks of unittests near the actual code. Consider 
>> unittested objects/structs, in each unittest you'll have to 
>> instantiate and stuff with mocks if needed and test a small 
>> piece of functionality from them. Also there is a problem with 
>> mocked objects where they will go? If every bit of 
>> functionality will be tested in same module with source code, 
>> then unittest / line of actual code will be much more to 
>> unittests part. It will make your module hard to navigate and 
>> discover what your source code is actually doing. So having a 
>> separate module with unittests indeed will help in making more 
>> claner and more understandable since they won't interfere with 
>> actual code.
>
> Also if you use templates with unittests sometimes private 
> symbols may succeed in the unittest, but fail when the template 
> is used in practice.
>
> Such bugs have existed in Phobos plenty of times.

Yes, but for the record they got extinct since ~ one year once 
CircleCi with its setup test extraction pipeline started to 
enforce this. There's no reason DMD couldn't do this by default 
internally when it finds a public unittest. Or  your favorite 
build tool could do such an extraction though granted then you do 
loose the "built-in", simplistic aspect of unittests.


More information about the Digitalmars-d-announce mailing list