What's new:

Built-in unittest blocks can now have a name with just a string UDA:
--------------------------------------------------------------------

@("test that does stuff") unittest {... }

Why is this important? If you just want to run unit tests in threads and have them named, you don't need to import unit_threaded in your source code anymore. I'm going to build on this later with a tool to make it so that existing codebases can benefit from unit_threaded without using it directly.


Value-parametrized tests
------------------------

Have you ever written a test that looks like this?

unittest {
    foreach(v; [...]) {
        //test code
    }
}


I have, and when it fails you have no idea which of the values caused the failure. Now, you can do this:

@(42, 2, 3)
void testValues(int i) {
    (i % 2 == 0).shouldBeTrue;
}

testValues will be run once for each value UDA with the same type in its declaration (in this case, int). Each run will be considered a different test and reported as such with the value that was used. In the above case, the output will contain this:

tests.pass.attributes.testValues.42:
tests.pass.attributes.testValues.2:
tests.pass.attributes.testValues.3:
    tests/pass/attributes.d:76 - Expected: true
    tests/pass/attributes.d:76 -      Got: false

Test tests.pass.attributes.testValues.3 failed.


Enjoy!

Atila

On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:
> What's new:
> <snip>
>
> Enjoy!
>
> Atila

Thanks! What is the relevant link?

On Tuesday, 9 February 2016 at 17:07:15 UTC, earthfront wrote:
> On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:
>> What's new:
>> <snip>
>>
>> Enjoy!
>>
>> Atila
>
> Thanks! What is the relevant link?

First link on DuckGo: https://github.com/atilaneves/unit-threaded

On 9/02/2016 12:23 AM, Atila Neves wrote:
> What's new:
>
> Built-in unittest blocks can now have a name with just a string UDA:
> --------------------------------------------------------------------
>
> @("test that does stuff") unittest {... }
>

I feel obliged to point out that this is going to be a disaster as soon as any other library decides that means something else.

On Saturday, 13 February 2016 at 12:41:35 UTC, Daniel Murphy wrote:
> On 9/02/2016 12:23 AM, Atila Neves wrote:
>> What's new:
>>
>> Built-in unittest blocks can now have a name with just a string UDA:
>> --------------------------------------------------------------------
>>
>> @("test that does stuff") unittest {... }
>>
>
> I feel obliged to point out that this is going to be a disaster as soon as any other library decides that means something else.

The @Name UDA still exists, and I think it's unlikely another library will be looking for string UDAs on unittest blocks that isn't itself a testing library.

Atila

On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:
> What's new:
>
> [...]
>
> Enjoy!
>
> Atila

I just started using unit-threaded and I like it so far, specially the parallel runner. Just had some speed-bumps that might be worth noting.

Before going into details I want to mention that I am not using it the way it is supposed to be used, which voids me from warranty I suppose.

From what I gather the normal way would be to create separate test-files with test-cases and unittest blocks inside them, completely separate from normal code.

Two things that made me go in the opposite direction was dub and code coverage.

So I don't have separate test files; I have the unittest blocks interspersed with code. Because I don't want to include unit_threaded in production code I ended up doing this:

version (unittest)
{
  include unit_threaded;
  @Name("Test test")
  unittest
  {
    ...
  }
}

Which is redundant, but I need the import outside the unittest for the UDA, and I don't want the import to show up in production code.

Then to get `dub test` to run unit_threaded I had to create a small program that discovers all modules and generates a testrunner.d file in the source directory, which gets picked up by dub. So now instead of `dub test` I call `rdmd test.d`, which generates the testrunner.d and calls dub test.

I feel I am going against the grain here.

Oh, kuddos for the nice library.

On 2016-02-16 23:13, Sebastiaan Koppe wrote:

> Then to get `dub test` to run unit_threaded I had to create a small
> program that discovers all modules and generates a testrunner.d file in
> the source directory, which gets picked up by dub. So now instead of
> `dub test` I call `rdmd test.d`, which generates the testrunner.d and
> calls dub test.
>
> I feel I am going against the grain here.

"dub test" will generate a program that discovers all modules. Not sure if it's compatible with unit-threaded.

-- 
/Jacob Carlborg

On Wednesday, 17 February 2016 at 07:46:51 UTC, Jacob Carlborg wrote:
> On 2016-02-16 23:13, Sebastiaan Koppe wrote:
>
>> Then to get `dub test` to run unit_threaded I had to create a small
>> program that discovers all modules and generates a testrunner.d file in
>> the source directory, which gets picked up by dub. So now instead of
>> `dub test` I call `rdmd test.d`, which generates the testrunner.d and
>> calls dub test.
>>
>> I feel I am going against the grain here.
>
> "dub test" will generate a program that discovers all modules. Not sure if it's compatible with unit-threaded.

It isn't, but I found a workaround. Dub has the preBuildCommands which allows you to run shell commands,. It now runs my small util that generates a testrunner compatible with unit-threaded. So now its just `dub test` again. Plus I can add modules as arguments so only those will be tested. (e.g. dub test -- my.module). This is a godsend.

On Tuesday, 16 February 2016 at 22:13:15 UTC, Sebastiaan Koppe wrote:
> On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:
>> What's new:
>>
>> [...]
>>
>> Enjoy!
>>
>> Atila
>
> I just started using unit-threaded and I like it so far, specially the parallel runner. Just had some speed-bumps that might be worth noting.
>
> Before going into details I want to mention that I am not using it the way it is supposed to be used, which voids me from warranty I suppose.
>
> From what I gather the normal way would be to create separate test-files with test-cases and unittest blocks inside them, completely separate from normal code.
>
> Two things that made me go in the opposite direction was dub and code coverage.
>
> So I don't have separate test files; I have the unittest blocks interspersed with code. Because I don't want to include unit_threaded in production code I ended up doing this:
>
> version (unittest)
> {
>   include unit_threaded;
>   @Name("Test test")
>   unittest
>   {
>     ...
>   }
> }
>
> Which is redundant, but I need the import outside the unittest for the UDA, and I don't want the import to show up in production code.
>
> Then to get `dub test` to run unit_threaded I had to create a small program that discovers all modules and generates a testrunner.d file in the source directory, which gets picked up by dub. So now instead of `dub test` I call `rdmd test.d`, which generates the testrunner.d and calls dub test.
>
> I feel I am going against the grain here.

I'm on a tablet on holiday so sorry in advance for the short answer. Your versioned import is the reason why I made it so a plain string UDA is just as good as @Name. That way you only need to import unit_threaded once in a version block, and only if you want to use the shouldXXX assertions.

The test runner you mentioned can be generated by using my dtest tool, also on dub.

The next thing on my TODO list is to make it even easier to opt-in to using unit-threaded without having to change existing project code

Atila