[Seaside-dev] self shouldnt: [ whatever ] raise: Error.

[Johan Brichau]

So...

Apart from that, it is safe to actually remove the assertions and count on the error being thrown to mark the test as an (erroneous) failure.
I've got the changes pending for commit... or do we want to raise this issue?

Next, it seems we will need to duplicate and adapt the Seaside-Core-Pharo20-Tests to Seaside-Core-Pharo30-Tests because of a deprecation of #ensureFile to #ensureCreateFile. Since probably more changes are coming anyway, I guess it's something we need to do.

Johan

On 21 Oct 2013, at 11:08, Philippe Marschall <philippe.marschall at gmail.com> wrote:

> On Sun, Oct 20, 2013 at 4:17 PM, Johan Brichau <johan at inceptive.be> wrote:
>> Indeed.
>> 
>> In the case of the now failing tests in Seaside, it is actually meaningful to test if no error is thrown. The assertion is a documentation what is being tested.
>> At first thought, I had the idea that it was easy to remove the assertion since the test will fail if an error is thrown anyway. However, without the assertion, the meaning of the test now has to be written in comments.
> 
> Exactly, it's the difference between a failure and an error.
> 
>> The spirit behind the idea seems good, but enforcing it like this is counter-productive in some cases.
> 
> Exactly, enterprise architect thinking.
> 
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev