On Tuesday, 27 August 2013 at 15:42:28 UTC, Andrej Mitrovic wrote:
> I have some of these functions here:
> https://github.com/AndrejMitrovic/minilib/blob/master/src/minilib/core/test.d

Where is your 'assertOp' from the comments of issue 4653?
I recently added it to https://github.com/linkrope/dunit

On 8/28/13, linkrope <linkrope@github.com> wrote:
> On Tuesday, 27 August 2013 at 15:42:28 UTC, Andrej Mitrovic wrote:
>> I have some of these functions here: https://github.com/AndrejMitrovic/minilib/blob/master/src/minilib/core/test.d
>
> Where is your 'assertOp' from the comments of issue 4653?
> I recently added it to https://github.com/linkrope/dunit

It appears I didn't add it! Thanks for reminding me.

On Tue, 2013-08-27 at 15:07 +0200, Atila Neves wrote:
> My very first D project is now feature-complete as far as I can see (alpha) and I'd like to share it with the community:
> 
> https://github.com/atilaneves/unit-threaded
> 
> There are more details on github but here are the highlights:

The trend in other languages, especially the Java-verse, is to use the same testing framework for unit, integration and some system testing. By using the name "Unit Threaded", and talking of unit testing, you seem to be stating that this framework is no good for integration and system testing, just unit testing. Is this the case?

Thanks.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Not at all. In fact, I was playing with using it to do
integration testing at work for our C++ code (it has a C
interface). I guess I was just focussed on unit testing because I
got annoyed at how long our unit tests* take to run, which was
what led me to write the C++11 version to begin with. After your
post I've got half a mind to try and speed up all aspects of
testing at work. Thanks!

I guess I or someone else will just have to try and use the
library for other types of testing and fix anything that might
need to be fixed.

I even mentioned at work that if I started a new company or large
project that I'd use D to write tests for anything with a C
interface. There's less glue to write (even with Swig, getting
the Python bindings to work can be a pain), it compiles lightning
fast and is just as nice as writing, say, Python.

Atila

* Even though part of the reason they take so long to run is that
quite a few of them are unit tests in name only, being
mini-integration tests in practice.

> The trend in other languages, especially the Java-verse, is to use the
> same testing framework for unit, integration and some system testing. By
> using the name "Unit Threaded", and talking of unit testing, you seem to
> be stating that this framework is no good for integration and system
> testing, just unit testing. Is this the case?
>
> Thanks.

I finally got around to putting it up in the dub registry.

http://code.dlang.org/packages/unit-threaded


On Tuesday, 27 August 2013 at 13:07:02 UTC, Atila Neves wrote:
> My very first D project is now feature-complete as far as I can see (alpha) and I'd like to share it with the community:
>
> https://github.com/atilaneves/unit-threaded
>
> There are more details on github but here are the highlights:
>
> 1. Automatic registration of unit tests via compile-time reflection
> 2. Unit tests can be classes or functions, the latter for minimal boilerplate
> 3. Support for D's unittest blocks
> 4. Runs in multiple threads by default, possible to run in one thread
> 5. Manual selection of tests to run at the command-line (runs all tests by default)
>
> I've used it myself to test my other D projects (2 other for now) to make sure it did what I wanted it to. I basically wrote this for myself knowing what I'd want from a unit testing library, but I'm sure it can be useful for the general D public.
>
> Feedback is of course more than welcome!
>
> Atila
>
> P.S. I totally expect this to break for large real-world projects in its current state. It can test some modules in phobos but had problems with others, for instance. My own other D projects are tiny and even if I had a large D codebase the tests I'd write would reflect the biases that go into this library.