On Saturday, September 03, 2016 13:36:06 Manu via Digitalmars-d wrote:
> This document: https://wiki.dlang.org/Contributing_to_Phobos
>
> States: "Avoid unittest in templates (it will generate a new unittest for each instance) - put your tests outside"
>
> Sounds reasonable, but then I realised that most of my unit tests are documenting unittests... this recommendation is in conflict with the documentation standards... who wins?

Well, do you want everyone who ever uses your template to have your unit tests in their code? Yes, having ddoc unit tests is great, but I for one definitely don't think that it's worth having the unit tests inside of the templates, since they end up in everyone's code, and I'd strongly argue that no unit tests that aren't meant to be generic should ever be in templates so long as the language works this way. That's why I created DIP 82:

http://wiki.dlang.org/DIP82

Unfortunately, it didn't generate much discussion and hasn't been implemented yet (which is often the case with DIPs), and now I need to figure out how to migrate it to the new DIP stuff on github and do that, or it's definitely not going anywhere. But I think that this is definitely a case where a language change is needed.

In any case, for now, I never put non-generic unit tests in templates, and I reject PRs that have them. Sure, having to copy-paste your examples sucks, but it doesn't affect the code of everyone who uses the template, whereas ddoc-ed unit tests do.

- Jonathan M Davis

On Saturday, 3 September 2016 at 12:46:23 UTC, Jonathan M Davis wrote:
> so long as the language works this way. That's why I created DIP 82:
>
> http://wiki.dlang.org/DIP82
>
> Unfortunately, it didn't generate much discussion and hasn't been implemented yet (which is often the case with DIPs), and now I need to figure out how to migrate it to the new DIP stuff on github and do that, or it's definitely not going anywhere. But I think that this is definitely a case where a language change is needed.

There's a migration tool that can help you to convert from the D Wiki to Markdown:

https://github.com/dlang/DIPs/tree/master/tools/dwikiquery

run it like

dub -- fetch --id 82

in case you don't have Pandoc installed, I have run a similar tool on most DIPs a couple of months ago, maybe that helps you:

https://github.com/wilzbach/d-dip/tree/gh-pages/md

Of course the conversion to Markdown isn't perfect and most probably requires a bit of manual tweaking. Also the header format between my crawl (yaml) and the new DIP repo (table) is different.

On Sat, Sep 03, 2016 at 05:46:23AM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Saturday, September 03, 2016 13:36:06 Manu via Digitalmars-d wrote:
> > This document: https://wiki.dlang.org/Contributing_to_Phobos
> >
> > States: "Avoid unittest in templates (it will generate a new unittest for each instance) - put your tests outside"
> >
> > Sounds reasonable, but then I realised that most of my unit tests are documenting unittests... this recommendation is in conflict with the documentation standards... who wins?
> 
> Well, do you want everyone who ever uses your template to have your unit tests in their code? Yes, having ddoc unit tests is great, but I for one definitely don't think that it's worth having the unit tests inside of the templates, since they end up in everyone's code, and I'd strongly argue that no unit tests that aren't meant to be generic should ever be in templates so long as the language works this way.

	version(libraryBuild) { version = do_unittest; }
	version(libraryDocs) { version = do_unittest; }

	///
	struct S(T) {
		///
		void method() { ... }

		///
		unittest { /* generic test here */ }

		version(do_unittest)
		///
		unittest { /* non-generic test here */ }
	}


> That's why I created DIP 82:
> 
> http://wiki.dlang.org/DIP82
> 
> Unfortunately, it didn't generate much discussion and hasn't been implemented yet (which is often the case with DIPs), and now I need to figure out how to migrate it to the new DIP stuff on github and do that, or it's definitely not going anywhere. But I think that this is definitely a case where a language change is needed.

It would certainly be nice, I agree.  But there *are* ways of working around this, even if they are a bit ugly (like above).


> In any case, for now, I never put non-generic unit tests in templates, and I reject PRs that have them. Sure, having to copy-paste your examples sucks, but it doesn't affect the code of everyone who uses the template, whereas ddoc-ed unit tests do.
[...]

Actually you don't need to copy-paste your examples, which IMO is a bad idea to begin with. Just version out the non-generic unittests when compiling user code, and you can have the best of both worlds.

In fact, versioning the unittests will also solve another problem: that of not compiling library unittests when user code is being compiled with -unittest (because the end user shouldn't need to bear the burden of running unittests for the library just because they want to unittest their own code).


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee

On Saturday, September 03, 2016 07:48:14 H. S. Teoh via Digitalmars-d wrote:
> > In any case, for now, I never put non-generic unit tests in templates, and I reject PRs that have them. Sure, having to copy-paste your examples sucks, but it doesn't affect the code of everyone who uses the template, whereas ddoc-ed unit tests do.
>
> [...]
>
> Actually you don't need to copy-paste your examples, which IMO is a bad idea to begin with. Just version out the non-generic unittests when compiling user code, and you can have the best of both worlds.

And you still have the problem that all of those unit tests will be compiled into every instantiation of the template that's part of your unittest build. So, you end up with longer build times and longer run times for your unit tests. I agree that copy-pasting sucks, but it's what we had to do before with had ddoc-ed unit tests, and I still think that it's better than resulting in all of the additional copies of the tests being compiled in and run - especially if the project isn't small.

- Jonathan M Davis

On Saturday, 3 September 2016 at 15:58:51 UTC, Jonathan M Davis wrote:
> On Saturday, September 03, 2016 07:48:14 H. S. Teoh via Digitalmars-d wrote:
>> > In any case, for now, I never put non-generic unit tests in templates, and I reject PRs that have them. Sure, having to copy-paste your examples sucks, but it doesn't affect the code of everyone who uses the template, whereas ddoc-ed unit tests do.
>>
>> [...]
>>
>> Actually you don't need to copy-paste your examples, which IMO is a bad idea to begin with. Just version out the non-generic unittests when compiling user code, and you can have the best of both worlds.
>
> And you still have the problem that all of those unit tests will be compiled into every instantiation of the template that's part of your unittest build. So, you end up with longer build times and longer run times for your unit tests. I agree that copy-pasting sucks, but it's what we had to do before with had ddoc-ed unit tests, and I still think that it's better than resulting in all of the additional copies of the tests being compiled in and run - especially if the project isn't small.
>
> - Jonathan M Davis

No need for that - see my other post: http://forum.dlang.org/post/psrgjdlvsiukkuhrekoo@forum.dlang.org