Re: documented unit tests as examples

2016-05-15 Thread Lutger via Digitalmars-d
On Friday, 13 May 2016 at 21:00:04 UTC, Steven Schveighoffer wrote: On 5/13/16 4:55 PM, Meta wrote: When I was new to D and I first saw the `assert(...)` idiom in an example in the documentation, it confused me for a minute or two, but if you know what `assert` does you can quickly wrap your

Re: documented unit tests as examples

2016-05-14 Thread Ryan Frame via Digitalmars-d
On Saturday, 14 May 2016 at 17:48:48 UTC, Andrej Mitrovic wrote: So anyway, I think perhaps the simplest solution is to make ddoc inject the writeln calls (or possibly replace assertions altogether in the output). The problem with replacing the assert is the loss of information.

Re: documented unit tests as examples

2016-05-14 Thread H. S. Teoh via Digitalmars-d
On Sat, May 14, 2016 at 03:32:45PM +0200, Andrej Mitrovic via Digitalmars-d wrote: [...] > Add a new compiler switch (or better yet use a built-in version > switch) which makes all assertions chatty. > > So for a unittest like this: > > > auto sum (a, b) => a + b; > > /// > unittest {

Re: documented unit tests as examples

2016-05-14 Thread Andrej Mitrovic via Digitalmars-d
On 5/13/16, Steven Schveighoffer via Digitalmars-d wrote: > I'm wondering if we can have a mechanism for documented unit tests to > have a slightly different showing inside the docs vs. the actual unit test. > > For example, let's say we have a function writelnAssert.

Re: documented unit tests as examples

2016-05-14 Thread Seb via Digitalmars-d
On Friday, 13 May 2016 at 21:27:25 UTC, Steven Schveighoffer wrote: A potential way to fix this may be marking a unit test as being a complete example program that assumes the user has installed proper access to the library. Then it won't compile unless you add the correct imports, and it's