On 01/25/2011 11:10 AM, foobar wrote:
The simple syntax of
>
> /++ Example +/
> unittest
> {
> }
>
>
> making that unittest block go in the documentation of the preceding function
> should work just fine. We already have /++ Ditto +/ which puts a function in
with
> the preceding function'
On Mon, 24 Jan 2011 17:32:12 -0500, Andrew Wiley
wrote:
Here's another approach:
When you think about it, what we're after is tagging unit tests as code
examples, so why not do exactly that with annotations?
@example(Foo.bar)
unittest {
//...
}
It means there are no new keywords to worry abo
On Tuesday 25 January 2011 02:10:49 foobar wrote:
> Jonathan M Davis Wrote:
> > On Monday 24 January 2011 15:27:08 foobar wrote:
>
>
> > > Unit-tests are defined on a module level, not a function level, hence I
> > > would expect to see the unit-tests that serve as examples to appear in
> > > an
Jonathan M Davis Wrote:
> On Monday 24 January 2011 15:27:08 foobar wrote:
> >
> > Unit-tests are defined on a module level, not a function level, hence I
> > would expect to see the unit-tests that serve as examples to appear in an
> > examples section on the page the documents the module itsel
Jonathan M Davis wrote:
> On Monday 24 January 2011 15:27:08 foobar wrote:
> > Steven Schveighoffer Wrote:
> > >
> > > This only makes sense if:
> > >
> > > 1. The unit test immediately follows the item being documented
> > > 2. The unit test *only* tests that item.
> > >
> > > The second one co
On Monday 24 January 2011 15:27:08 foobar wrote:
> Steven Schveighoffer Wrote:
> > On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
> >
> > wrote:
> > > On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
> > >> On 1/24/11 1:50 PM, Jens Mueller wrote:
> > >>> Jonathan M Davis wrote:
> > I
Steven Schveighoffer Wrote:
> On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
> wrote:
>
> > On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
> >> On 1/24/11 1:50 PM, Jens Mueller wrote:
> >>> Jonathan M Davis wrote:
> I think that it's been discussed a time or two, but nothing has
On 01/24/2011 10:03 PM, Andrei Alexandrescu wrote:
One other thing, using writefln is considered bad form in unit tests
(you want *no* output if the unit test works). But many examples might
want to demonstrate how e.g. an object interacts with writefln. Any
suggestions? The assert line above is
On Mon, Jan 24, 2011 at 3:43 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
>
>> On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
>> wrote:
>>
>>> I find documented unittests attractive mainly because they're
>>> _simple_.
Steven Schveighoffer napisał:
>> BTW I consider this a very important topic. We have _plenty_ of
>> examples that don't work and are not mechanically verifiable. The
>> reasons range from minor typos to language changes to implementation
>> limitations. Generally this is what they call "documentat
On Monday, January 24, 2011 13:35:22 Andrei Alexandrescu wrote:
> On 1/24/11 3:16 PM, Nick Sabalausky wrote:
> > "Andrej Mitrovic" wrote in message
> > news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
> >
> >> It's often the case that you want documentation examples to be short,
>
On Mon, 24 Jan 2011 16:43:39 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
I find documented unittests attractive mainly because they're
_simple_. As soon as we start to add that kind of stuf
Andrei Alexandrescu wrote:
Documentation is a reference, not a novel. If someone looked up the
documentation for "bar", why make them jump over to "foo" (and make sure
they know to do so) to see bar's examples?
Then there better are two examples, one focused on foo and the other on
bar. Any
On Mon, 24 Jan 2011 16:36:21 -0500, Steven Schveighoffer
wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
Yah, that is an issue. For examples that do non-unittesty stuff (e.g.
writeln, use sockets etc.) we can still use the old-style documentation.
That sounds rea
On 01/25/2011 12:16 AM, Nick Sabalausky wrote:
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't
Steven Schveighoffer wrote:
If DIP9 is accepted (writeTo), then showing examples of how the format
specifiers work would certainly look less confusing via writefln.
I thought this was what std.format was for.
--
Simen
On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
I find documented unittests attractive mainly because they're
_simple_. As soon as we start to add that kind of stuff... exponential
decay.
It's only not simple if you want it to be.
On Mon, 24 Jan 2011 16:07:38 -0500, Andrej Mitrovic
wrote:
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I
On 1/24/11 3:16 PM, Nick Sabalausky wrote:
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want
On 1/24/11 3:12 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ihkpin$194m$1...@digitalmars.com...
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
The second one could be pretty annoying. Consider cases where several
functions interact (I've seen this many times on Micr
Daniel Gibson wrote:
> Am 24.01.2011 21:39, schrieb Jens Mueller:
> >Andrei Alexandrescu wrote:
> >>On 1/24/11 1:50 PM, Jens Mueller wrote:
> >>>Jonathan M Davis wrote:
> I think that it's been discussed a time or two, but nothing has been done
> about
> it. It wouldn't be entirely str
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
> It's often the case that you want documentation examples to be short,
> but also correct. But you still want to write complex unittests that
> you don't want to put in the documentation. Sounds li
"Andrei Alexandrescu" wrote in message
news:ihkpin$194m$1...@digitalmars.com...
> On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
>> The second one could be pretty annoying. Consider cases where several
>> functions interact (I've seen this many times on Microsoft's
>> Documentation), and it make
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests:
unittest(ddoc)
{
// outputted in documentation
}
Here "ddo
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
On Monday 24 January 2011 12:15:07 Andrei Alexandrescu wrote:
> On 1/24/11 1:50 PM, Jens Mueller wrote:
> > Jonathan M Davis wrote:
> >> I think that it's been discussed a time or two, but nothing has been
> >> done about it. It wouldn't be entirely straightforward to do.
> >> Essentially, either a
Am 24.01.2011 21:39, schrieb Jens Mueller:
Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittes
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straight
Andrei Alexandrescu wrote:
> On 1/24/11 1:50 PM, Jens Mueller wrote:
> >Jonathan M Davis wrote:
> >>I think that it's been discussed a time or two, but nothing has been done
> >>about
> >>it. It wouldn't be entirely straightforward to do. Essentially, either a
> >>unittest block would have to be g
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be generated from the Examples section in the
docu
Jonathan M Davis wrote:
> On Monday, January 24, 2011 09:55:52 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > In case you didn't know, I have a set of unit test helper functions which
> > > have been being reviewed for possible inclusion in phobos. Here's an
> > > update.
> > >
> > > Most r
On Monday, January 24, 2011 09:55:52 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > In case you didn't know, I have a set of unit test helper functions which
> > have been being reviewed for possible inclusion in phobos. Here's an
> > update.
> >
> > Most recent code: http://is.gd/F1OHat
> >
>
Jonathan M Davis wrote:
> In case you didn't know, I have a set of unit test helper functions which
> have
> been being reviewed for possible inclusion in phobos. Here's an update.
>
> Most recent code: http://is.gd/F1OHat
>
> Okay. I took the previous suggestions into consideration and adjuste
35 matches
Mail list logo