the return of the strange methods
Survey: who uses the following methods? and if yes why? - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString I honestly cannot wrap my head around these two methods.
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it! frank
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? 2013/7/9 Frank Shearar <frank.shearar@gmail.com>
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
On 09.07.2013, at 17:42, Clément Bera <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
+1
2013/7/9 Frank Shearar <frank.shearar@gmail.com> On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
-mgvnf mk. / On Jul 9, 2013 11:49 AM, "Max Leske" <maxleske@gmail.com> wrote:
On 09.07.2013, at 17:42, Clément Bera <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of
Error, but not lazy enough to create a test and copy paste a String.
Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
+1
2013/7/9 Frank Shearar <frank.shearar@gmail.com>
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent
whoseDescriptionDoesNotInclude: subString.- description: aString
- shouldnt: aBlock raise: anExceptionalEvdcdvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
On 9 July 2013 16:42, Clément Bera <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
If something should not raise a KeyNotFound exception, which would you regard as more useful: "KeyNotFound" or "'foo' key not found" ? frank
2013/7/9 Frank Shearar <frank.shearar@gmail.com>
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation. So, +A LOT to remove them. Esteban On Jul 9, 2013, at 5:42 PM, Clément Bera <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
2013/7/9 Frank Shearar <frank.shearar@gmail.com> On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
On 9 July 2013 17:42, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation.
So, +A LOT to remove them.
No. Failing to specify your error messages is a colossal fail. And if you don't _test_ your error messages, how are you going to know you haven't just made your error messages utterly useless in that last refactoring? And no, checking that your KeyNotFound exception's #key is correctly set is insufficient, because you then _presume_ that the process of reporting the exception actually bothers to record that and doesn't just say "a KeyNotFound". By all means use a proper exception that captures semantic meaning. But, please, PLEASE actually test your logging. frank
Esteban
On Jul 9, 2013, at 5:42 PM, Clément Bera <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
2013/7/9 Frank Shearar <frank.shearar@gmail.com>
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
On 2013-07-09, at 18:48, Frank Shearar <frank.shearar@gmail.com> wrote:
On 9 July 2013 17:42, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation.
So, +A LOT to remove them.
No. Failing to specify your error messages is a colossal fail. And if you don't _test_ your error messages, how are you going to know you haven't just made your error messages utterly useless in that last refactoring?
That is a separate test for your Exception: MyExceptionTest >> testMessage | message | message := self targetClass new description. ... I don't see the point in testing the description string somewhere else...
And no, checking that your KeyNotFound exception's #key is correctly set is insufficient, because you then _presume_ that the process of reporting the exception actually bothers to record that and doesn't just say "a KeyNotFound".
I do not fully see the point of testing that a certain exception is not signaled. 1. if an exception is signaled the test will fail anyways 2. if exceptions are signaled you can easily test that using something like: self should: [ .. ] raise: (NotFound, ZeroDivide, ...) 3. If you have a test that returns different exceptions in the tests you have nondeterminism, so that basically invalidates point 2. 3. Since you have deterministic tests you know that only one kind of error is signaled hence it suffices to use the #should:raise:... methods. Hence, I really do not see the point of the complex #shouldnt:raise:whoseDescriptionIncludes: 1. #shouldnt:raise: is more less fine. Though I would expect it ignore all the other errors thrown, which it doesn't essentially limiting the use of this method. 2. #shouldnt:raise:whoseDescriptionIncludes: is too complex. 3. #shouldnt:raise:whoseDescriptionDoesNotIncludes: essentially reads like a double negation which confuses the hell out of me ----------------------------------------------------------------------------------------- Example: -------- self shouldnt: [ ... ] raise: MyException whoseDescriptionIncludes: 'PING'. What does that mean for the following blocks? 1. [ Error signal ] 2. [ Error signal: 'PING' ] 3. [ MyException signal ] 4. [ MyException signal: 'PING' ] 3 and 4 definitely fail, I assume 1 fails too, and the only one left is case 2. And the monstrous #shouldnt:raise:whoseDescriptionDoesNotInclude: will only pass in case 1? ----------------------------------------------------------------------------------------- In any case, nobody uses the complex #shouldnt:raise:whose* methods so I am removing them and simplify the implementation of TAssertable.
On 9 juil. 2013, at 18:42, Esteban Lorenzano wrote:
Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation.
So, +A LOT to remove them.
Agree Moreover, I really don't see why we should have a special assertion for auditing the description of an Error. If you begin like that you end up with tons of highly specific assertion for tons of specific objects: self assert: aCollection hasSizeLowerThan: 10. self assert: aPoint isBelow: 2@3. self assert: myDomainObject satisfiesSomeDomainSpecificConstraintParametrizedBy: anObject and: anotherObject ... No way!
Esteban
On Jul 9, 2013, at 5:42 PM, Clément Bera <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
2013/7/9 Frank Shearar <frank.shearar@gmail.com> On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
M/I/i On Jul 9, 2013 11:43 AM, "Clément Bera" <bera.clement@gmail.com> wrote:
They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. Then you write in your method: self error: 'some strange error happened' And you can test it: self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange'
Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ?
2013/7/9 Frank Shearar <frank.shearar@gmail.com>
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
frank
On 2013-07-09, at 17:30, Frank Shearar <frank.shearar@gmail.com> wrote:
On 9 July 2013 16:24, Camillo Bruni <camillobruni@gmail.com> wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.
So + 1 :)
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.
"should not raise an exceptional event whose description does not include" wow, who is crooked enough to use double negation ;) Nicolas 2013/7/9 Stéphane Ducasse <stephane.ducasse@inria.fr>
So + 1 :)
- shouldnt: aBlock raise: anExceptionalEvent
whoseDescriptionDoesNotInclude: subString description: aString
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.
Maybe this would be more clear? aBlock doNotRaise: anException unlessDescriptionIncludes: aString aBlock doNotRaise: anException ifDescriptionIncludes: aString All the best, Ron Teitelbaum From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolas Cellier Sent: Tuesday, July 09, 2013 4:45 PM To: Pharo Development List Subject: Re: [Pharo-dev] the return of the strange methods "should not raise an exceptional event whose description does not include" wow, who is crooked enough to use double negation ;) Nicolas 2013/7/9 Stéphane Ducasse <stephane.ducasse@inria.fr> So + 1 :)
- shouldnt: aBlock raise: anExceptionalEvent
whoseDescriptionDoesNotInclude: subString description: aString
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.
On 9 July 2013 22:45, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
"should not raise an exceptional event whose description does not include" wow, who is crooked enough to use double negation ;)
is it a convenience method for following: [ self dosomething ] on: Error do: [:ex | self assert: ex message includes:'whatever' ] ? as to me this is more readable and intent-revealing than using strange double-negation..
Nicolas
2013/7/9 Stéphane Ducasse <stephane.ducasse@inria.fr>
So + 1 :)
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.
-- Best regards, Igor Stasenko.
On 10 juil. 2013, at 16:45, Igor Stasenko wrote:
On 9 July 2013 22:45, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
"should not raise an exceptional event whose description does not include" wow, who is crooked enough to use double negation ;)
is it a convenience method for following:
[ self dosomething ] on: Error do: [:ex | self assert: ex message includes:'whatever' ] ?
Not really, because it doesn't fails if no exception is raised.
as to me this is more readable and intent-revealing than using strange double-negation..
What you want is a TAssertable>>#should:raise: that: - takes a one arg block as second argument that is evaluated with the exception thrown - fails if no exception is raised
Nicolas
2013/7/9 Stéphane Ducasse <stephane.ducasse@inria.fr>
So + 1 :)
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString
I honestly cannot wrap my head around these two methods.
They show that the code in the block raises an _informative_ exception. So you get a FileNotFound exception... but what was the missing file? I don't know! Noone bothered to mention it!
no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.
-- Best regards, Igor Stasenko.
What you want is a TAssertable>>#should:raise: that: - takes a one arg block as second argument that is evaluated with the exception thrown - fails if no exception is raised
Then please call it #should:raise:suchThat: That's what is in upcoming SUnit 5.0 [1] Also I would avoid using traits in SUnit, this is non-portable. The TestAsserter class was introduced already in SUnit 4.0. Indeed, only if you at all care about having SUnit in sync with other dialects :-) Best, Jan [1]: https://swing.fit.cvut.cz/hg/stx.goodies.sunit/file/fb932a5daa97/TestAsserte...
I would really like to have Sunit 5 in Pharo. Stef On Jul 10, 2013, at 6:45 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
What you want is a TAssertable>>#should:raise: that: - takes a one arg block as second argument that is evaluated with the exception thrown - fails if no exception is raised
Then please call it #should:raise:suchThat: That's what is in upcoming SUnit 5.0 [1]
Also I would avoid using traits in SUnit, this is non-portable. The TestAsserter class was introduced already in SUnit 4.0. Indeed, only if you at all care about having SUnit in sync with other dialects :-)
Best, Jan
[1]: https://swing.fit.cvut.cz/hg/stx.goodies.sunit/file/fb932a5daa97/TestAsserte...
On Jul 11, 2013, at 8:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would really like to have Sunit 5 in Pharo.
Of course we added lots of things to Sunit, so this means rewriting tests. (e.g. skip). And we will get the sunit* methods back⦠I hate them :-)
Stef
On Jul 10, 2013, at 6:45 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
What you want is a TAssertable>>#should:raise: that: - takes a one arg block as second argument that is evaluated with the exception thrown - fails if no exception is raised
Then please call it #should:raise:suchThat: That's what is in upcoming SUnit 5.0 [1]
Also I would avoid using traits in SUnit, this is non-portable. The TestAsserter class was introduced already in SUnit 4.0. Indeed, only if you at all care about having SUnit in sync with other dialects :-)
Best, Jan
[1]: https://swing.fit.cvut.cz/hg/stx.goodies.sunit/file/fb932a5daa97/TestAsserte...
On Jul 11, 2013, at 8:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jul 11, 2013, at 8:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would really like to have Sunit 5 in Pharo.
Of course we added lots of things to Sunit, so this means rewriting tests. (e.g. skip).
And we will get the sunit* methods back⦠I hate them :-)
this is why we should - have the possibility to have two different Unit frameworks - take the time to get the new version. Stef
On 2013-07-11, at 09:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: > On Jul 11, 2013, at 8:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote: >> On Jul 11, 2013, at 8:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: >> >>> I would really like to have Sunit 5 in Pharo. >>> >> >> Of course we added lots of things to Sunit, so this means rewriting tests. (e.g. skip). >> >> And we will get the sunit* methods back⦠I hate them :-) > this is why we should > - have the possibility to have two different Unit frameworks > - take the time to get the new version. It only makes sense to adapt the public methods on TestCase, the rest we should keep or rewrite. We really need a separate test runner (not UI, but model) as it is done in SMark for instance.
On 11/07/13 07:32, Marcus Denker wrote:
On Jul 11, 2013, at 8:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would really like to have Sunit 5 in Pharo.
Of course we added lots of things to Sunit, so this means rewriting tests. (e.g. skip).
And we will get the sunit* methods backâ¦
You sure? Because back in ESUG in Barcelona, Niall spent a spent a *lot* of time with variaos people re-checking whether there is a common method in all supported dialects so we may kill as many of those a possible. I hate them :-)
Stef
On Jul 10, 2013, at 6:45 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
What you want is a TAssertable>>#should:raise: that: - takes a one arg block as second argument that is evaluated with the exception thrown - fails if no exception is raised
Then please call it #should:raise:suchThat: That's what is in upcoming SUnit 5.0 [1]
Also I would avoid using traits in SUnit, this is non-portable. The TestAsserter class was introduced already in SUnit 4.0. Indeed, only if you at all care about having SUnit in sync with other dialects :-)
Best, Jan
[1]: https://swing.fit.cvut.cz/hg/stx.goodies.sunit/file/fb932a5daa97/TestAsserte...
participants (13)
-
Camille Teruel -
Camillo Bruni -
Clément Bera -
Esteban Lorenzano -
Frank Shearar -
Igor Stasenko -
Jan Vrany -
Jeff Estep -
Marcus Denker -
Max Leske -
Nicolas Cellier -
Ron Teitelbaum -
Stéphane Ducasse