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