Actually - all those methods are already there - it looks like no-one could 
decide, so I agree that it should be small and concise - however equally test 
failures should be clear and easy to deal with - which is where assert:equals: 
is brilliant - such a huge time saver when you hit it, as you can easily 
understand the problem. So similarly, deny:equals: is a big saver as well - you 
get the same immediate feedback that confirms what happened in a test.

If the interface is too thin - and you have to create all these helper methods 
yourself - its just a pain.  But it would be good to agree on whether we are 
using assert or should.

Tim

> On 10 Aug 2018, at 16:16, Joachim Tuchel <jtuc...@objektfabrik.de> wrote:
> 
> I personally think that the methods you suggest as examples pollute the API 
> without adding any value. Just because Java and others added these doesn’t 
> justify a bad API. SUnit was intended to be mean and lightweight. Adding lots 
> of permutations to it doesn’t actually make it any better, just ugly.
> 
> I see some space for improvements in logging and keeping details for CI 
> scenarios, however.
> 
> Joachim
> 
> Am 10.08.2018 um 10:33 schrieb Guillermo Polito <guillermopol...@gmail.com 
> <mailto:guillermopol...@gmail.com>>:
> 
>> Personally I think that SUnit needs love. 
>>  - The API is clearly not clear (just see: the command line handler, 
>> smalltalk ci, calypso and the test runner tool use different APIs that are 
>> not equivalent and do not go through the same hooks)
>>  - The existing hooks are not enough and not well documented, other than 
>> overriding #runCase:, how can we define parameterizable tests for example?
>> 
>> With Julien (in cc) we were thinking some improvements on this front. He has 
>> a new UI for the test runner that is cleaner and will allow having different 
>> backends (which will mean also that we will need to clarify the API).
>> 
>> I think in Pharo7 there have been some improvements in the assertions front?
>> 
>> On Thu, Aug 9, 2018 at 3:07 PM Tim Mackinnon <tim@testit.works 
>> <mailto:tim@testit.works>> wrote:
>> I’m trying to write more exercism tests and I’m baffled why there isn’t the 
>> inverse equivalent of #assert:equals: which shows a useful test response 
>> where you can easily see what’s going on.
>> 
>> #assert:equals: is very nice, showing you a diff browser - I kind of expect 
>> the opposite to be there, but it all looks like a bit of mess with assert vs 
>> should and deny vs shouldn’t -did we change tact somewhere over the years 
>> and not deprecate stuff?
>> 
>> Tim
>> 
>> 
>> -- 
>>    
>> Guille Polito
>> Research Engineer
>> 
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>> CRIStAL - UMR 9189
>> French National Center for Scientific Research - http://www.cnrs.fr 
>> <http://www.cnrs.fr/>
>> 
>> Web: http://guillep.github.io <http://guillep.github.io/>
>> Phone: +33 06 52 70 66 13

Reply via email to