Hi Chris,

yes, tests should be as modular and concise as possible -- only checking for "one thing" in each test. However, #assert: is *not* the level of granularity one should look at to judge a certain test's modularity. That is, there can be more than one #assert: in a test and still the test be regarded as testing "one thing".

So... I do not quite agree with your statement here ... but I think you mean the right thing:

> Expected failures should be put into their own #test.. method
> and not mixed with assertions that are expected to pass. Otherwise,
> the SUnit domain won't be able to properly express to you the state of
> those tests, as you said.


One should not compose tests according to pass-or-not but rather following domain/project-specific reasons.

Then, I know about some tests that put a guard in the beginning of a test to provide a useful "failure message" to the user before running into some other assertion failures.

Still not so sure about this hook, though, ... hmmm...

Best,
Marcel
Am 26.05.2019 22:01:02 schrieb Chris Muller <ma.chris.m at gmail.com>:
On Sun, May 26, 2019 at 2:20 PM Jakob Reschke <forums.jakob at resfarm.de [mailto:forums.jakob at resfarm.de]> wrote:

Am So., 26. Mai 2019 um 20:56 Uhr schrieb Chris Muller <asqueaker at gmail.com [mailto:asqueaker at gmail.com]>:

Right.  Expected failures should be put into their own #test.. method
and not mixed with assertions that are expected to pass.  Otherwise,
the SUnit domain won't be able to properly express to you the state of
those tests, as you said.


Makes sense. Hope everyone is aware of that for the future use of the feature.

And for present use, too, since mixing them would present the same issue today as well.  As the test developer is required to specify expectedFailures at #test..method level, they'll probably be naturally inclined to put only that group of should:'s in there.  They're generally rare, exceptional cases.

 

PS.

I came across an apparent "self
contradiction" in the spec.


> Whew I tried to read "self contradiction" as a Smalltalk expression at first... :-)

That sounds like an interesting behavior, we should implement that on Object!   :-) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190527/e19bd09e/attachment.html>