August 15, 2018
On Wednesday, 15 August 2018 at 14:33:26 UTC, Steven Schveighoffer wrote:
> On 8/12/18 11:07 AM, Anton Fediushin wrote:
>> Hello, I'm glad to announce that silly v0.0.1 is released.
>> 
>> Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments.
>> 
>> Instead of using dub as part of the test runner or hacking into `preBuildCommands` silly seamlessly integrates into `dub test` requiring user to just add it as a dependency into dub.json or dub.sdl.
>> 
>> Check out project's website [1], repository [2] and page on dub registry [3] where you can find more information.
>> 
>> [1]: https://ohboi.gitlab.io/silly/
>> [2]: https://gitlab.com/ohboi/silly
>> [3]: https://silly.dub.pm/
>> 
>
> I notice that you're using the new unittest system added in 2.078, but bypassing the reporting mechanism (i.e. using exit instead of returning). Is there a reason why?
>
> This is exactly the type of thing I envisioned would be used when developing said feature. I'm asking because I'd like to understand what the limitations are that caused you to bypass it.
>
> -Steve

Thanks for pointing it out, I never really looked into that. I used `exit` before because everything was split into functions, so it was simpler to just `exit` than return things here and there.

It's fixed now in v0.0.2. I'm still using own printer for summary, because built-in one is boring:

---
Summary: 2 passed, 2 failed in 0 ms
---
vs
---
2/4 unittests FAILED
---

August 15, 2018
On Wednesday, 15 August 2018 at 14:01:24 UTC, rikki cattermole wrote:
> On 16/08/2018 1:31 AM, Bogdan Szabo wrote:
>> I wonder if the test runners could provide a template for the injected code, that dub could use it on `dub test`. I wonder if we could add something like `"testRunner": "trial"` in the dub.json file.
>
> I've thought about this a bit. Adding special support for test runners does seem like a bad idea. An alternative could be to enable injection of a mixin template by the compiler for each compiler parsed. You can either get an alias to initialize a template for only type purposes, or you can throw a module constructor in.
>
> That would enable more interesting use cases like route registration for web routers.

I disagree, adding special support for test runners is great, in fact dub already has that (it uses `tested` if it's installed). What we need to do is just extend this feature a little bit and tell the ones who develop test runners to update them accordingly. I'd be happy to have that and I think Atila and Bogdan too.

Also, dub has special support for documentation generators that are compatible with ddox. There's `"-ddoxTool"` configuration option. I think we could do the same with test runners being compatible with tested.
September 12, 2018
On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote:
> Hello, I'm glad to announce that silly v0.0.1 is released.
>
> Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments.
In my local version I've modified the test name to be colorized. Could you add this feature? it really helps the readability in my opinion.

Either way, I really love silly! Thanks a lot!


September 12, 2018
On Wednesday, 12 September 2018 at 04:02:14 UTC, Soulsbane wrote:
> On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote:
>> Hello, I'm glad to announce that silly v0.0.1 is released.
>>
>> Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments.
> In my local version I've modified the test name to be colorized. Could you add this feature? it really helps the readability in my opinion.

I doubt that will make it more readable, in fact it'd annoy me. Another thing to consider is the fact that colours in terminal are highly customizable so if something works and most importantly looks good for somebody it might look terrible and be unreadable on different terminal preferences.

This is something I experienced with trial which colours test names white and vibe-core's logger which used different shades of grey for different log levels. Both of these as you can imagine are unreadable on black-on-white terminals.

>
> Either way, I really love silly! Thanks a lot!

You are welcome!

1 2
Next ›   Last »