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

bauss jj_1337 at live.dk
Thu Mar 22 12:25:59 UTC 2018


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:
>>>> Blog post:
>>>>
>>>> https://atilanevesoncode.wordpress.com/
>>>>
>>>> Atila
>>>
>>> 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.


More information about the Digitalmars-d-announce mailing list