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