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.

Let me zoom out to the context of why I happened to need
#expectedFailure in the first place.  While implementing GraphQL
document validation code, I came across an apparent "self
contradiction" in the spec.  In one case, it says to handle scenario
XYZ one way, but in another place, it says to handle XYZ differently.
So I have to choose to implement one way or the other, and whichever
way I *don't* I want to document as an expectedFailure.

It actually ended up being a family of about 3 or 4 these cases, and I
got tired of seeing them in the SUnit browser, distracting me by
making me think they were something I needed to investigate...


On Sun, May 26, 2019 at 9:01 AM Jakob Reschke <forums.jakob at resfarm.de> wrote:
>
> Am Fr., 24. Mai 2019 um 04:39 Uhr schrieb <commits at source.squeak.org>:
>>
>>
>>   ----- Method: TestCase>>assert: (in category 'accessing') -----
>>   assert: aBooleanOrBlock
>>
>> +       aBooleanOrBlock value = self shouldPass ifFalse: [self signalFailure: 'Assertion failed']
>> -       aBooleanOrBlock value ifFalse: [self signalFailure: 'Assertion failed']
>>                         !
>>
>
> Hmm, what if a test case has multiple assertions and only one of them fails under certain conditions, which is why the test is expected to fail under these conditions? If only the last of many assertions fails so far, so the complete test method runs, after this change the first assertion will fail right away (because it is true contrary to shouldPass), won't it? It might hide some errors, like exceptions raised in the middle of the assertions.
>