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
