www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE unit tests

reply 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
Jul 15 2013
next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e013cb6e4d80ff504e1930303
Content-Type: text/plain; charset=ISO-8859-1

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) --089e013cb6e4d80ff504e1930303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 10:34 AM, Jacob Carlborg <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wro= te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Recently I added a new trait to get all the unit tests functions from a mod= ule. With this in place, among other things, it&#39;s possible to do unit t= ests for CTFE functions. Here&#39;s a quick try:<br> <br> <a href=3D"http://pastebin.com/Kk0in3bD" target=3D"_blank">http://pastebin.= com/Kk0in3bD</a><br> <br></blockquote><div>great, thanks</div><div>=A0</div><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"> What&#39;s missing is CTFE-able &quot;writeln&quot;.<br></blockquote><div><= br></div><div>awaiting <a href=3D"https://github.com/D-Programming-Language= /dmd/pull/692">https://github.com/D-Programming-Language/dmd/pull/692</a> o= r CTFE exec</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> It&#39;s also possible to implement named unit tests in library code, now w= hen it&#39;s possible to access UDA&#39;s from the unit test functions.</bl= ockquote><div><br></div><div>I would still prefer the short and sweet synta= x:=A0</div> <div>unittest(myunittestname){...}</div><div>rather than the cumbersome:</d= iv><div> named(&quot;myunittestname&quot;)</div><div>unittest{...}</div><di= v><br></div><div>These named unittests would ideally be referable to inside= DDOC (as opposed to current horrible practice of duplicating examples insi= de documentation, which are never in sync)=A0</div> <div><br></div><div>Later, for a more complete testing infrastructure, we w= ould 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)</div> </div> --089e013cb6e4d80ff504e1930303--
Jul 15 2013
prev sibling next sibling parent "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
Jul 15 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e013a100aad02fd04e1936c89
Content-Type: text/plain; charset=ISO-8859-1

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). --089e013a100aad02fd04e1936c89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 2:07 PM, Dicebot <span dir=3D"ltr">&lt;<a href=3D"m= ailto:public dicebot.lv" target=3D"_blank">public dicebot.lv</a>&gt;</span>= wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Monday, 15 July 2013 at 20:50:59 UTC, Timothee Cour wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> These named unittests would ideally be referable to inside DDOC (as opposed= <br> to current horrible practice of duplicating examples inside documentation,<= br> which are never in sync)<br> </blockquote> <br> </div><a href=3D"http://dlang.org/changelog.html#documentedunittest" target= =3D"_blank">http://dlang.org/changelog.<u></u>html#documentedunittest</a><b= r> </blockquote></div><br><div>Thanks, forgot it appeared in 2.063. Now the fe= ature just needs to be used ! (so many out of date examples embedded in doc= umentation at the moment).</div> --089e013a100aad02fd04e1936c89--
Jul 15 2013
prev sibling parent "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.
Jul 15 2013