I would really like to have Sunit 5 in Pharo.
Stef
On Jul 10, 2013, at 6:45 PM, Jan Vrany jan.vr...@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
On Jul 11, 2013, at 8:32 AM, Marcus Denker marcus.den...@inria.fr wrote:
On Jul 11, 2013, at 8:26 AM, Stéphane Ducasse stephane.duca...@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.
On 9 July 2013 22:45, Nicolas Cellier
nicolas.cellier.aka.n...@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 |
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
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
On 9 July 2013 16:24, Camillo Bruni camillobr...@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
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
On 09.07.2013, at 17:42, Clément Bera bera.clem...@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
On 9 July 2013 16:42, Clément Bera bera.clem...@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
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,
On 9 July 2013 17:42, Esteban Lorenzano esteba...@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.
On 2013-07-09, at 17:30, Frank Shearar frank.shea...@gmail.com wrote:
On 9 July 2013 16:24, Camillo Bruni camillobr...@gmail.com wrote:
Survey: who uses the following methods? and if yes why?
- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude:
subString
On 2013-07-09, at 18:48, Frank Shearar frank.shea...@gmail.com wrote:
On 9 July 2013 17:42, Esteban Lorenzano esteba...@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
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
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.duca...@inria.fr
So + 1 :)
- shouldnt: aBlock raise: anExceptionalEvent
whoseDescriptionDoesNotInclude: subString
15 matches
Mail list logo
