Hi Markus,
> What is wrong with writing:
> IntervalTest >> testRemove
> self should: [(1 to: 3) remove: 2] raise: Exception
There's nothing wrong with your test, but I prefer more specific errors.
Why? probably because I prefer to run my tests automatically and then write a structured report.
I work with VW, and when I search senders of methods like 'subclassRes*', I find senders of "subclassResponsability", "subClassResponsability", "subClassResponsibility" and so on. it's difficult to stay clean with selectors, and it's worst with strings.
Once I had to check all the messages written in a server's log file. I had plenty of messages with the same meanning but with different sentences because each time a programmer had to log something (informations or errors), he wrote a specific string.
I assume that when you
have a Class hierarchy for errors, people tend to look at the hierarchy instead of creating their own errors, and as most of the time your kind of error is roughly the same as one already written.
Regards,
Pascal
Markus Gaelli wrote:
Hi Pascal,
> It would be easier to catch and therefore to test with a specific
> subclass of Exception.
What is wrong with writing:
IntervalTest >> testRemove
self should: [(1 to: 3) remove: 2] raise: Exception
> Besides, for the Interval>>remove: example, the code would have been:
>
> Interval>> remove: anElement
> "elements cannot be removed from an Interval"
> ^self shouldNotImplement
So I need to browse the method and cannot see directly anymore what
is going in
the label of my walkback-window?
>
> Mind you, even in VW you have these calls of error:, and
> shouldNotImplement is implemented that way...
> But why not implementing shouldNotImplement like:
>
> Object>> shouldNotImplement
> ^ShouldNotImplementError raise
Why?
Cheers,
Markus
Yahoo! Cars
NEW - sell your car and browse thousands of new and used cars online search now
Locked
