Blog post:

https://atilanevesoncode.wordpress.com/

Atila

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

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.

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.

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.

On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves wrote:
> Blog post:
>
> https://atilanevesoncode.wordpress.com/
>
> Atila

I *love* built-in unittests. Putting them right after each function makes things so much easier.

Tests in their own file is something from 90-s. It's 2018 and I want to be able to write tests anywhere I want.

"They increase build times" - fix compiler, not my code.

"version(unittest) will cause you problems if you write libraries" - fix dub, not my code.

Built-in unittests are part of D's specification. As long as it allowes to do so, I'll carry on writing unittests in my code and nobody can take it from me.

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.

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.

Faster as measured by what? Projects definitely take longer to build and iterate on.

If you think it makes things easier, great! The blog post is my opinion.

Atila

On Thursday, 22 March 2018 at 12:26:14 UTC, Anton Fediushin wrote:
> On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves wrote:
>> Blog post:
>>
>> https://atilanevesoncode.wordpress.com/
>>
>> Atila
>
> I *love* built-in unittests. Putting them right after each function makes things so much easier.

If it works for you, great.

> Tests in their own file is something from 90-s. It's 2018 and I want to be able to write tests anywhere I want.

You _can_ write them wherever you want. I'm not arguing for taking any flexibility away, I'm arguing that for most projects it's a bad idea, and I stated the reasons why I think that's the case. Feel free to disagree.

> "They increase build times" - fix compiler, not my code.

If by "fix the compiler" you mean "make it so that the compiler knows exactly what files need to be recompiled if I only edited the body of a unittest block" (which is what would be needed), then I don't think that'll happen any time soon.

But sure, if the compiler worked that way I'd happily advocate for writing unittests in the same file. But for now, I'd rather spend a lot less time staring at the screen for 2s waiting for my code to be built. That's my trade-off, and reasonable people may (and apparently quite obviously do) disagree.

> "version(unittest) will cause you problems if you write libraries" - fix dub, not my code.

This is _not_ a dub issue. version(unittest) _will_ bite you as soon as you compile foo.d with -unittest because its imports will be parsed differently. This is one to stick in the "fix the compiler" column. See the link to the since-reverted Phobos PR in the blog.

> Built-in unittests are part of D's specification. As long as it allowes to do so, I'll carry on writing unittests in my code and nobody can take it from me.

Who's trying to take it from you?

Atila

On Thursday, 22 March 2018 at 11:00:31 UTC, Atila Neves wrote:

> Direct link:
>
> https://atilanevesoncode.wordpress.com/2018/03/22/keep-d-unittests-separated-from-production-code/

I completely agree. Although my reason is mostly because there will be too much code in a single file if the regular code and unit tests are mixed in the same file. Also, having utilities/helpers only used by the tests is easier, or easier to find a location for.

--
/Jacob Carlborg