[Pharo-users] The confusing state of SUnit

Tim Mackinnon tim at testit.works
Wed Feb 27 04:44:24 EST 2019


No - my point is, why are the basics for reasonable testing not in the image? Such that tests are easy, and a joy to write where failures are obvious when they occur.

We seem to have 2 extremes - assert:equals: does a lovely job of showing what it expects and you got with a nice diff view (that is fab) - then the other extreme of testing an exception message which is unfathomable….

I’m not asking for all the esoteric combinations - but a good foundation to build tests on should be in the image. Extra bells and wistles should be easy to load for more advanced testing. (We kind of have that, but its spread across multiple projects that might be consolidat-able).

SUnit is now 30 years old - advancements have been made, and the other xUnit derivatives now all do a much better job than us which makes me very sad.

As mentioned, we do equality (and inequality) well, collection equality looks good too - exception testing is present but not good enough.
I also argue that  "greater and less than" are common, as are some basic collection checks (notably String begins, ends, contains and regex).

I agree with the argument that we don’t want to bloat the image - but doing the above well is so important to ensure we can easily write great tests, particularly when we find a problem and want to whip up at test to help understand how to solve it (many of our tests in the image are not as helpful as they could be).

Is there at least some agreement to sorting this out? Could we put it on the 8.0 roadmap (its a tiny win, and quite easy to do - although cleaning up the old tests to use better features is a harder job - but worth it IMHO).

This all comes out of my casual work on Exercism, which is about teaching people how to use a core language/environment and demonstrate how amazing that environment is. In many respects our advancements show case well :
- zero conf lets us get an environment up and running in peoples hands in less than a minute (I don’t think many of the other 30 language on there can do this) 
- git/tonel/zinc lets us play nicely with their cloud based platform
- opal/moldable debugger/undeclared variables lets us do TDD as it was meant to be
- iceberg (and GitHub) lets us create a project where community contribution is easy

I think we still fall a bit short in our IDE (not faulting Calypso - its still work in progress and needs more help), testing (as per above), language documentation (we have too much old out of date stuff).

The good far outweighs the needs improvement, but the journey is still ongoing.


Tim


> On 27 Feb 2019, at 07:29, jtuchel at objektfabrik.de wrote:
> 
> So you are suggesting an extension of SUnit. Great. You just forgot to attach your code ;-)
> 
> BTW: I think the current imnplementations of SUnit already carry a large amount of pollution. Just because JUnit and friends introduced special methods for testing equality and such, we also have this noise in SUnit.
> This is not to say your suggestion would be useless. Just make a proposal and let's discuss.
> 
> 
> Joachim
> 
> 
> Am 27.02.19 um 01:14 schrieb Tim Mackinnon:
>> Forgive me father, for I have sinned… but when I try to right good tests, that fail in a way I can understand them it seems that SUnit doesn’t want to help me…
>> 
>> Maybe I am missing something, but in 2019 it should be easy to write tests - particularly when we want people to contribute to adding more?
>> 
>> So when I want to right a test to assure that I’ve thrown an exception with the right message, why is it so hard (in the core image)? Am I missing something obvious?
>> 
>> My example model is supposed to throw a DomainException with a message indicating that the strings :are of different lengths” - I search Sunit and hit:
>> 
>> 
>> #should: raise: whoseDescriptionDoesNotInclude: description:
>> 
>> Awesome, so it fails - but does it make it easy to know what damn string I got….. nooooo that would be too easy? Its almost impossible to easily see what happened the way it works.
>> 
>> Instead I have to write:
>> 
>> self
>> 		should: [ hammingCalculator distanceStrand1: 'AATG' strand2: 'AAA' ]
>> 		raise: DomainError
>> 		withExceptionDo: [ :ex |
>> 			self assert: ex messageText equals: 'left and right strands must be of equal length' ].
>> 		
>> 
>> And god forbid if I want to just ensure that the beginning of my error message is correct?
>> 
>> Why do we make this so hard? I know we don’t want to pollute the image, but testing is important, it should be easy for obvious cases and it should be more built in and less obscure. Is there something built in that makes this easier? Do I really have to load in more libraries for the easy cases?
>> 
>> Tim
>> 
>> 
>> 
> 
> -- 
> -----------------------------------------------------------------------
> Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de
> Fliederweg 1                         http://www.objektfabrik.de
> D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
> Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
> 
> 
> 




More information about the Pharo-users mailing list