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
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> 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
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 <guillermopolito@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> 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
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 <jtuchel@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 <guillermopolito@gmail.com <mailto:guillermopolito@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
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 <jtuchel@objektfabrik.de <mailto:jtuchel@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 <guillermopolito@gmail.com <mailto:guillermopolito@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
participants (4)
-
Guillermo Polito -
Herbert VojÄÃk -
Joachim Tuchel -
Tim Mackinnon