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.