Smalltalk › Pharo › Pharo Smalltalk Users

Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Tim Mackinnon

Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

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

Guillermo Polito

Re: Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

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 <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

jtuchel

Re: Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

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 <[hidden email]>:

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 <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Tim Mackinnon

Re: Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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

Web: http://guillep.github.io
Phone: +33 06 52 70 66 13

Herby Vojčík

Re: Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

If you want expressive DSL for various assertions, Mocketry has one.

I sort-of used to this approach from JS testing where mocha actually
expects you will use your own assertion lib (eg. chai).

Herby

Tim Mackinnon wrote on 10. 8. 2018 16:34:

> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>> <[hidden email] <mailto:[hidden email]>>:
>>
>>> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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
>>>
>