• Jacob Carlborg (9/9) Jul 15 2013 Recently I added a new trait to get all the unit tests functions from a
• Timothee Cour (14/22) Jul 15 2013 I would still prefer the short and sweet syntax:
• Dicebot (2/7) Jul 15 2013 http://dlang.org/changelog.html#documentedunittest
• Timothee Cour (3/10) Jul 15 2013 Thanks, forgot it appeared in 2.063. Now the feature just needs to be us...
• H. S. Teoh (50/65) Jul 15 2013 One problem with these ddoc-unittest, though, is that you still have

Jacob Carlborg <doob me.com> writes:

Recently I added a new trait to get all the unit tests functions from a 
module. With this in place, among other things, it's possible to do unit 
tests for CTFE functions. Here's a quick try:

http://pastebin.com/Kk0in3bD

What's missing is CTFE-able "writeln".

It's also possible to implement named unit tests in library code, now 
when it's possible to access UDA's from the unit test functions.

-- 
/Jacob Carlborg

Timothee Cour <thelastmammoth gmail.com> writes:

On Mon, Jul 15, 2013 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:

 Recently I added a new trait to get all the unit tests functions from a
 module. With this in place, among other things, it's possible to do unit
 tests for CTFE functions. Here's a quick try:

 http://pastebin.com/Kk0in3bD

 great, thanks


 What's missing is CTFE-able "writeln".

awaiting https://github.com/D-Programming-Language/dmd/pull/692 or CTFE exec


 It's also possible to implement named unit tests in library code, now when
 it's possible to access UDA's from the unit test functions.


I would still prefer the short and sweet syntax:
unittest(myunittestname){...}
rather than the cumbersome:
 named("myunittestname")
unittest{...}

These named unittests would ideally be referable to inside DDOC (as opposed
to current horrible practice of duplicating examples inside documentation,
which are never in sync)

Later, for a more complete testing infrastructure, we would need additional
attributes indicating for example whether the unittest is
near-instantaneous or takes a long time to run (to filter out slow ones
when needed)

"Dicebot" <public dicebot.lv> writes:

On Monday, 15 July 2013 at 20:50:59 UTC, Timothee Cour wrote:
 These named unittests would ideally be referable to inside DDOC 
 (as opposed
 to current horrible practice of duplicating examples inside 
 documentation,
 which are never in sync)

http://dlang.org/changelog.html#documentedunittest

Timothee Cour <thelastmammoth gmail.com> writes:

On Mon, Jul 15, 2013 at 2:07 PM, Dicebot <public dicebot.lv> wrote:

 On Monday, 15 July 2013 at 20:50:59 UTC, Timothee Cour wrote:

 These named unittests would ideally be referable to inside DDOC (as
 opposed
 to current horrible practice of duplicating examples inside documentation,
 which are never in sync)

 http://dlang.org/changelog.**html#documentedunittest<http://dlang.org/changelog.html#documentedunittest>

Thanks, forgot it appeared in 2.063. Now the feature just needs to be used
! (so many out of date examples embedded in documentation at the moment).

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Jul 15, 2013 at 02:20:06PM -0700, Timothee Cour wrote:
 On Mon, Jul 15, 2013 at 2:07 PM, Dicebot <public dicebot.lv> wrote:
 
 On Monday, 15 July 2013 at 20:50:59 UTC, Timothee Cour wrote:

 These named unittests would ideally be referable to inside DDOC (as
 opposed
 to current horrible practice of duplicating examples inside documentation,
 which are never in sync)

 http://dlang.org/changelog.**html#documentedunittest<http://dlang.org/changelog.html#documentedunittest>

 
 Thanks, forgot it appeared in 2.063. Now the feature just needs to be used
 ! (so many out of date examples embedded in documentation at the moment).

One problem with these ddoc-unittest, though, is that you still have
some issues when writing ddocs for templated structs/classes. For
example:

	struct MyStruct(T) {
		/// Docs for MyMethod
		void MyMethod(...) {
			...
		}

		/// ddoc-unittest
		unittest {
			MyStruct!int exampleStruct;
			...
		}
	}

The problem is that your unittest will be instantiated for every type T
that you instantiate MyStruct with, even though the resulting code is
identical (it's generally a good idea to explicitly write, e.g.,
MyStruct!int in ddoc unittests, since you want users to see a concrete
example, not something involving T implicitly or explicitly). This
wastes memory when compiling, and increases program startup time by
running redundant tests.

One workaround is to use static if to restrict the instantiation of the
unittest:

	struct MyStruct(T) {
		/// Docs for MyMethod
		void MyMethod(...) {
			...
		}

		static if (is(T == int)) {
			/// ddoc-unittest
			unittest {
				MyStruct!int exampleStruct;
				...
			}
		}
	}

	// Force instantiation of MyStruct!int so that unittest will
	// actually get instantiated once!
	//
	// Problem: if you forget to do this, your unittest may never
	// actually be compiled, so it doesn't actually run.
	version(unittest)
		MyStruct!int _dummy;

This isn't ideal, since there's possibility of bugs if you forget that
last part to instantiate MyStruct!int: your unittest will never actually
run. Plus, it's a hassle to keep typing out these static ifs.


T

-- 
In order to understand recursion you must first understand recursion.