Y'know what we need? This compiler flag:

   -unittest=pagkage.name.*

Damn near every codebase in D uses "unittest{}" sections. Obviously that's good.

But it's also bad:

I cannot flip on unittests for my project (where "I" and "my" can be substituted with the name of any D user) without *also* flipping on unittests for every source-library used, transitively. Unless the lib versions-out their unittests with "version(Unittest_MyLibXXX)"...And none of them do. (well, mostly)

This *can* be fine, *when*:

- They're all fast.

- Their sum doesn't make DMD's memory usage go kabloom.

- They all have all their prereqs already setup (sometimes the need for
  some configuration isn't easily avoidable, example: setting up a DB
  user/login).

- And none of them have any failures...on the *exact*
  OS/arch/compiler/compiler-version combination that I happen to be
  using. Oh, and the exact versions of any other dependent libs.

We could say "Let's just recommend good style is to version out your unittest blocks". But that's programming by convention: All it takes is one lib not playing ball, or one unittest in one lib that just happened to forget it, and then the poor user is back to "ad-hoc patching"-land. And it's boiler-plate, anyway.

So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running
out the door)

On Mon, May 20, 2013 at 6:52 PM, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> Y'know what we need? This compiler flag:
>
>    -unittest=pagkage.name.*
>

I would like that as well.

Here's a workaround in the meantime:
dmd -c -unittest a;
dmd -c b;
dmd -oftest -main -unittest *.o
./test => will only run unittest of a, not b.

Another thing we need is named unittests:

unittest(my_test_1){...}

It's been requested so many times and I still don't get the arguments
against them.
Here's a common workflow:

1) I write a function fun.
2) I write a function test_fun that tests fun.
3) I run test_fun in isolation (saves time, only need to run that)
4) Later on, once its debugged I turn test_fun into a unittest.

Having unittest(test_fun){...} would simplify this routine.



> Damn near every codebase in D uses "unittest{}" sections. Obviously that's good.
>
> But it's also bad:
>
> I cannot flip on unittests for my project (where "I" and "my" can be substituted with the name of any D user) without *also* flipping on unittests for every source-library used, transitively. Unless the lib versions-out their unittests with "version(Unittest_MyLibXXX)"...And none of them do. (well, mostly)
>
> This *can* be fine, *when*:
>
> - They're all fast.
>
> - Their sum doesn't make DMD's memory usage go kabloom.
>
> - They all have all their prereqs already setup (sometimes the need for
>   some configuration isn't easily avoidable, example: setting up a DB
>   user/login).
>
> - And none of them have any failures...on the *exact*
>   OS/arch/compiler/compiler-version combination that I happen to be
>   using. Oh, and the exact versions of any other dependent libs.
>
> We could say "Let's just recommend good style is to version out your unittest blocks". But that's programming by convention: All it takes is one lib not playing ball, or one unittest in one lib that just happened to forget it, and then the poor user is back to "ad-hoc patching"-land. And it's boiler-plate, anyway.
>
> So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running
> out the door)
>
>

On 2013-05-21 03:52, Nick Sabalausky wrote:
> Y'know what we need? This compiler flag:
>
>     -unittest=pagkage.name.*

I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.

-- 
/Jacob Carlborg

Jacob Carlborg:

> I wouldn't say no to that flag.

D built-in unittests are rather under-engineered. Some standard way to run only part of the unittests is necessary.

Bye,
bearophile

Jacob Carlborg wrote:
> On 2013-05-21 03:52, Nick Sabalausky wrote:
> >Y'know what we need? This compiler flag:
> >
> >    -unittest=pagkage.name.*
> 
> I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.

It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested.

Jens

On Tue, May 21, 2013 at 12:35 AM, Jens Mueller <jens.k.mueller@gmx.de>wrote:

> Jacob Carlborg wrote:
> > On 2013-05-21 03:52, Nick Sabalausky wrote:
> > >Y'know what we need? This compiler flag:
> > >
> > >    -unittest=pagkage.name.*
> >
> > I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.
>
> It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested.
>
> Jens
>

That looks good, will try. However it doesn't address the issue of individual unittests (see 2nd post). Compiler support is needed for named unittests.

Timothee Cour wrote:
> On Tue, May 21, 2013 at 12:35 AM, Jens Mueller <jens.k.mueller@gmx.de>wrote:
> 
> > Jacob Carlborg wrote:
> > > On 2013-05-21 03:52, Nick Sabalausky wrote:
> > > >Y'know what we need? This compiler flag:
> > > >
> > > >    -unittest=pagkage.name.*
> > >
> > > I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.
> >
> > It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested.
> >
> > Jens
> >
> 
> That looks good, will try. However it doesn't address the issue of individual unittests (see 2nd post). Compiler support is needed for named unittests.

Johannes Pfau had a pull request for that very feature.
But I'd argue running separate unittests is the only feature that is
strictly needed from the compiler.
I mean to have named unittests you can use either UDAs

@name("myname")
unittest
{
}

or something like

unittest
{
    unittestName("myname");
}

Either way this is already doable in a good manner.
If there was a possibility to execute individual unittests it'll be
straightforward to add named unittests to dtest.
dmd developers are a scarce resource.

Jens

On 2013-05-21 09:35, Jens Mueller wrote:

> It is possible and we shouldn't push functionality into the compiler
> when the issue is solvable in a library.
> https://github.com/jkm/dtest (shameless plug) has the command line
> switch --include to specify which modules should be tested.

I'm using an rspec influenced library I wrote:

https://github.com/jacob-carlborg/dspec

Not very advanced. I still need a good way to run the tests. Now I'm just using a shell script. To see it in action, have a look here:

https://github.com/jacob-carlborg/orange/tree/master/tests

Yes, it does some operator overload abuse.

-- 
/Jacob Carlborg

Jacob Carlborg wrote:
> On 2013-05-21 09:35, Jens Mueller wrote:
> 
> >It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested.
> 
> I'm using an rspec influenced library I wrote:
> 
> https://github.com/jacob-carlborg/dspec
> 
> Not very advanced. I still need a good way to run the tests. Now I'm just using a shell script. To see it in action, have a look here:
> 
> https://github.com/jacob-carlborg/orange/tree/master/tests
> 
> Yes, it does some operator overload abuse.

I have already seen it. I'm also looking for a more natural way to write
tests. dspec goes in that direction but I found its syntax
(describe("...") in {} and it("...") in {}) not convincing.
I was thinking about something like
a.should == 10;
or similar. But that has its own problems. Anyway writing/executing
unittests in D needs to become more fun.

Jens

On 2013-05-21 14:34, Jens Mueller wrote:

> I have already seen it. I'm also looking for a more natural way to write
> tests. dspec goes in that direction but I found its syntax
> (describe("...") in {} and it("...") in {}) not convincing.

I really, REALLY would like to be able to have a syntax like this:

describe("foo")
{
    it("bar")
    {
        // asserts
    }
}

> I was thinking about something like
> a.should == 10;
> or similar. But that has its own problems. Anyway writing/executing
> unittests in D needs to become more fun.

That syntax is the next step for dspec. But that would be put inside the it-blocks, not instead of. It would be instead of the asserts.

-- 
/Jacob Carlborg