www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - unit-threaded v1.0.0

reply Atila Neves <atila.neves gmail.com> writes:
I decided to stop being like Google and finally tag version 1 of 
unit-threaded:

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

 From now on I'm going to focus on compilation speed (no matter 
how ugly that might make the implementation), and also dropping 
support in v2.x.x for anything other than unittest blocks (bye 
bye test classes and functions).
May 28 2020
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2020-05-28 at 15:35 +0000, Atila Neves via Digitalmars-d-announce
wrote:

 I decided to stop being like Google and finally tag version 1 of=20
 unit-threaded:
=20
 https://code.dlang.org/packages/unit-threaded
=20
  From now on I'm going to focus on compilation speed (no matter=20
 how ugly that might make the implementation), and also dropping=20
 support in v2.x.x for anything other than unittest blocks (bye=20
 bye test classes and functions).


This last is sad, for me. I like using test functions rather than named
unittest blocks.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
May 28 2020
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:

 [snip]

 This last is sad, for me. I like using test functions rather 
 than named unittest blocks.


I recall playing with them when it was originally announced and 
thought they were quite nice, but I haven't used them since.

The unit-threaded library certainly seems chocked full of 
features. Some of them overlap with the fluent-asserts library. 
It may make sense to split off some of that stuff as well so that 
people can evaluate custom assert libraries on their own merits.

Similarly, the mocking and integration stuff could probably (?) 
be split off into separate packages. This would imply 
unit-threaded could be focused on the runner subpackage.
May 28 2020
parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 28 May 2020 at 19:01:22 UTC, jmh530 wrote:

 On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:

 [snip]

 This last is sad, for me. I like using test functions rather 
 than named unittest blocks.


 I recall playing with them when it was originally announced and 
 thought they were quite nice, but I haven't used them since.

 The unit-threaded library certainly seems chocked full of 
 features. Some of them overlap with the fluent-asserts library. 
 It may make sense to split off some of that stuff as well so 
 that people can evaluate custom assert libraries on their own 
 merits.

 Similarly, the mocking and integration stuff could probably (?) 
 be split off into separate packages. This would imply 
 unit-threaded could be focused on the runner subpackage.


The assertions are their own subpackage, as is the runner, and 
mocking, and integration.
Jun 01 2020
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:

 On Thu, 2020-05-28 at 15:35 +0000, Atila Neves via 
 Digitalmars-d-announce wrote:

 I decided to stop being like Google and finally tag version 1 
 of unit-threaded:
 
 https://code.dlang.org/packages/unit-threaded
 
  From now on I'm going to focus on compilation speed (no matter
 how ugly that might make the implementation), and also dropping
 support in v2.x.x for anything other than unittest blocks (bye
 bye test classes and functions).


 This last is sad, for me. I like using test functions rather 
 than named unittest blocks.


Out of curiosity, what is the difference for you between:

testFoo() { /* ... */ }

and:

 ("foo")
unittest { /* ... */ }
Jun 01 2020
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2020-06-01 at 08:41 +0000, Atila Neves via Digitalmars-d-announce
wrote:
[=E2=80=A6]

 Out of curiosity, what is the difference for you between:
=20
 testFoo() { /* ... */ }
=20
 and:
=20
  ("foo")
 unittest { /* ... */ }


Primarily consistency with the way all other unit test frameworks which are
based on test functions =E2=80=93 I am not a fan of class-based unit tests =
hence using
pytest in favour of unittest in Python. Using functions just feels more
normal.

Secondarily lack of understanding of the scope rules of multiple unittest
blocks.

In the end though I use whatever is provided. So if functions are for the
chop, I will switch to using labelled unittest blocks.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Jun 01 2020
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 1 June 2020 at 09:08:01 UTC, Russel Winder wrote:



 Secondarily lack of understanding of the scope rules of 
 multiple unittest blocks.

 In the end though I use whatever is provided. So if functions 
 are for the chop, I will switch to using labelled unittest 
 blocks.


Each unittest block is a function.
Jun 01 2020
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
On 28.05.20 17:35, Atila Neves wrote:

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


You got a bad  trusted:

----
import unit_threaded.light: check;
void main()  safe
{
     check!((int a)  system {
         /* ... can do unsafe stuff here ... */
         return true;
     });
}
----

I searched for "trusted" and that was the first hit. I didn't look 
further. There's probably more.
May 29 2020
parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 29 May 2020 at 14:20:53 UTC, ag0aep6g wrote:

 On 28.05.20 17:35, Atila Neves wrote:

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


 You got a bad  trusted:

 ----
 import unit_threaded.light: check;
 void main()  safe
 {
     check!((int a)  system {
         /* ... can do unsafe stuff here ... */
         return true;
     });
 }
 ----

 I searched for "trusted" and that was the first hit. I didn't 
 look further. There's probably more.


That got fixed a few weeks back - your code doesn't compile for 
me.
Jun 01 2020
parent reply ag0aep6g <anonymous example.com> writes:
On 01.06.20 10:49, Atila Neves wrote:

 That got fixed a few weeks back - your code doesn't compile for me.


Huh. Maybe you forgot to commit that? I'm just running this through `dub 
--single test.d`:

----
/+ dub.json:
{
     "dependencies": {
         "unit-threaded": "~>1.0.0",
     },
}
+/
import unit_threaded.light: check;
void main()  safe
{
     check!((int a)  system {
         /* ... can do unsafe stuff here ... */
         return true;
     });
}
----

https://run.dlang.io/is/NbiYBB
Jun 01 2020
parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 1 June 2020 at 09:03:20 UTC, ag0aep6g wrote:

 On 01.06.20 10:49, Atila Neves wrote:

 That got fixed a few weeks back - your code doesn't compile 
 for me.


 Huh. Maybe you forgot to commit that? I'm just running this 
 through `dub --single test.d`:

 ----
 /+ dub.json:
 {
     "dependencies": {
         "unit-threaded": "~>1.0.0",
     },
 }
 +/
 import unit_threaded.light: check;
 void main()  safe
 {
     check!((int a)  system {
         /* ... can do unsafe stuff here ... */
         return true;
     });
 }
 ----

 https://run.dlang.io/is/NbiYBB


I missed that you imported `unit_threaded.light`. Thanks for 
reporting! That whole module needs to be redone.
Jun 02 2020