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
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
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
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
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
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
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
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
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
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
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