silly is released - new test runner for the D programming language

[Atila Neves]

On Monday, 13 August 2018 at 04:13:46 UTC, Anton Fediushin wrote:
> On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote:
>> On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin 
>> wrote:

> Problem with unit-threaded and similar tools is that they are 
> too complicated for no particular reason.

Yes, I often wake up and think to myself "what feature can I add 
that aren't going to be useful to anyone at all?" then write some 
code.

Nobody adds complication "for no particular reason". Even people 
who shouldn't be doing it do it because they're trying to 
accomplish something else.

> Hacking into dub.json to add some scripting into it is not 
> something everybody wants to waste their time on.

Agreed. Other than manually listing modules however (which is 
what I do these days anyway due to a dub bug), I don't know of a 
better way.

I wish there were a compile-time trait like __traits(allModules). 
I've thought of writing a DSI

> Another thing, these tools are trying to be everything people 
> might need adding all kinds of features nobody really uses. For 
> example, assertions in unit-threaded and a lot of different 
> reporters in trial.

This is a good point. I think I should split unit-threaded up 
into separate dub subpackages. Thanks for the idea!

> These tools also advertise usage of built-in `unittest` blocks 
> for integration testing. I think it's just wrong because 
> `unittest`s are obviously meant for unit testing and slapping 
> integration tests on with some duct tape and zip ties is not a 
> good solution. Integration testing needs it's own tool and it's 
> quite possible that I'll end up writing one soon or later.

I'm curious as to why you think that's the case.

> Silly is just my attempt to improve current state of D's 
> ecosystem where programmers don't use advanced test runners, 
> well, because it doesn't worth it for small projects.

The trouble with small projects is that they tend to not remain 
small if people find them useful. Also, even if they do, I'd 
still rather use a good test runner, the same way I don't think 
any project is too small for git.