Destroy https://issues.dlang.org/show_bug.cgi?id=13291?

Andrei

On Thursday, 14 August 2014 at 01:10:54 UTC, Andrei Alexandrescu wrote:
> Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
>
> Andrei

So it'll look like this?

functionBody:
     blockStatement
    | inStatement outStatement? bodyStatement?
    | outStatement inStatement? bodyStatement?
    | unittest bodyStatement
    | unittest inStatement outStatement? bodyStatement
    | unittest outStatement inStatement? bodyStatement
    | bodyStatement
    ;

That is, a unittest always requires a body, and thus can't be used in interfaces, correct?

On 8/13/14, 6:38 PM, Brian Schott wrote:
> On Thursday, 14 August 2014 at 01:10:54 UTC, Andrei Alexandrescu wrote:
>> Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
>>
>> Andrei
>
> So it'll look like this?
>
> functionBody:
>       blockStatement
>      | inStatement outStatement? bodyStatement?
>      | outStatement inStatement? bodyStatement?
>      | unittest bodyStatement
>      | unittest inStatement outStatement? bodyStatement
>      | unittest outStatement inStatement? bodyStatement
>      | bodyStatement
>      ;
>
> That is, a unittest always requires a body, and thus can't be used in
> interfaces, correct?

That's about right.

Andrei

On Thursday, 14 August 2014 at 01:38:56 UTC, Brian Schott wrote:
> On Thursday, 14 August 2014 at 01:10:54 UTC, Andrei Alexandrescu wrote:
>> Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
>>
>> Andrei
>
> So it'll look like this?
>
> functionBody:
>      blockStatement
>     | inStatement outStatement? bodyStatement?
>     | outStatement inStatement? bodyStatement?
>     | unittest bodyStatement
>     | unittest inStatement outStatement? bodyStatement
>     | unittest outStatement inStatement? bodyStatement
>     | bodyStatement
>     ;
>
> That is, a unittest always requires a body, and thus can't be used in interfaces, correct?

Well, there's nothing to test in abstract functions, is there?

I'm more concerned about the unit test appearing before the code, when the usual convention is to put the unit tests after the code they are testing...

On Thursday, 14 August 2014 at 02:04:09 UTC, Idan Arye wrote:
> Well, there's nothing to test in abstract functions, is there?
>
> I'm more concerned about the unit test appearing before the code, when the usual convention is to put the unit tests after the code they are testing...

There is precedence conceptually for putting unittests before code (TDD as an example of a technique that suggests unittests should be written first). Plus, in some ways it makes sense that unittests come first because it shows you how to use the function in question. I often look at unittests for examples of how to use code, almost like documentation (which also comes before the code).

Not to mention the fact that we'd have to come up with new syntax otherwise. The following is ambiguous:

    void blah(T)(...)
    in { ... }
    body { ... }
    unittest { ... }

Is the unittest
  1. part of the module and thus should only be run once
or is it
  2. part of the templated function and should be run per instantiation?

Current behavior is 1. So it'd be really necessary to come up with some new, unambiguous syntax to put the unittest after the function. Whereas the current proposal doesn't create an ambiguity and doesn't need new, special syntax to perform this task.

On Wed, Aug 13, 2014 at 06:10:54PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
[...]

1) How to add attributes to the unittest without them clashing with the function's attributes?

2) How to parse ddoc comments for the unittest?

3) Where should unittest block stand in relation to in/out contracts?

4) How much can you realistically test on a generic type argument T, that you can't already cover with concrete types? I'm finding that the per-instantiation behaviour of unittest blocks inside templated structs/classes is rarely desired, esp. when you write ddoc unittests (because you want code examples in the docs to involve concrete types, not abstract types, otherwise they are of limited use to the reader). Because of this, I often move unittests outside the aggregate or enclose them in static if's. This suggests that perhaps per-instantiation unittests are only of limited utility.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.

On Thursday, 14 August 2014 at 01:10:54 UTC, Andrei Alexandrescu wrote:
> Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
>
> Andrei

It's worth noting that you can currently do this:

template fun(T)
{
	int fun(T val)
	{
		static if(is(T == string) || is(T == float))
		{
			return 0;
		}
		else
		{
			return 1;
		}
	}
	
	unittest
	{
		assert(fun(T.init) == 0);
	}
}

void main()
{
	fun("test"); //Ok
	fun(3.0f);   //Ok
	fun(1);      //AssertError thrown
}

Does the proposal handle multiple unittest blocks?



On Wed, Aug 13, 2014 at 9:02 PM, H. S. Teoh via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wed, Aug 13, 2014 at 06:10:54PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> > Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
> [...]
>
> 1) How to add attributes to the unittest without them clashing with the function's attributes?
>
> 2) How to parse ddoc comments for the unittest?
>
> 3) Where should unittest block stand in relation to in/out contracts?
>
> 4) How much can you realistically test on a generic type argument T, that you can't already cover with concrete types? I'm finding that the per-instantiation behaviour of unittest blocks inside templated structs/classes is rarely desired, esp. when you write ddoc unittests (because you want code examples in the docs to involve concrete types, not abstract types, otherwise they are of limited use to the reader). Because of this, I often move unittests outside the aggregate or enclose them in static if's. This suggests that perhaps per-instantiation unittests are only of limited utility.
>
>
> T
>
> --
> "A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.
>

On 14/08/2014 05:02, H. S. Teoh via Digitalmars-d wrote:
> 4) How much can you realistically test on a generic type argument T,
> that you can't already cover with concrete types? I'm finding that the
> per-instantiation behaviour of unittest blocks inside templated
> structs/classes is rarely desired, esp. when you write ddoc unittests
> (because you want code examples in the docs to involve concrete types,
> not abstract types, otherwise they are of limited use to the reader).
> Because of this, I often move unittests outside the aggregate or enclose
> them in static if's.

Yes, which is bad as they can be some distance away from methods, so they might not be kept in sync. I think it's not possible to have a documented unittest for a method that isn't part of the parent template. This is necessary to prevent template instantiation recursion sometimes.

Perhaps we could have new syntax for that, e.g.:

struct S(T)
{
    void foo();

    // force module scope, not part of S
    module unittest()
    {
        S!int s;  // no instantiation recursion
        s.foo();
    }
}

Andrei Alexandrescu:
> Destroy https://issues.dlang.org/show_bug.cgi?id=13291?

I'd like a way to test nested functions:


void foo() {
    int bar() { return 0; }

    unittest {
        assert(bar() == 1);
    }
}

void main() {}


Bye,
bearophile