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 <email@example.com >> <mailto:firstname.lastname@example.org>> 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