<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Chris,<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">testMethodRegisteredAsAnExpectedFailure</span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> self assert: (falseExpression). "A"</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> self assert: (trueExpression). "B"</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Implemented like this, one should consider this as *one test* -- regardless of the number of assertions inside. Still, one might want to refactor it and swap the two lines to simplify debugging. However, that's only useful if the semantic order of both assertions got mixed up in the first place. It might have anything to do with the actual cause of the failure.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Still, one could *add* another test that focuses on the failing assertion -- if possible:</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><div style="font-size: 13.3333px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">testMethodRegisteredAsAnotherExpectedFailure</span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">   self assert: (falseExpression). "A"</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Makes it easier for the programmer to figure out what to fix first in the future. Both tests would be expected failures, though.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> But </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">expectedFailures are a subset *within* a domain-specific reason that</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> not only *should* (IMO), but *need* to be separated out, because SUnit</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> provides registration of expectedFailures ONLY at the #test... method</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> level.</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Hmm... no. Given that expected failures work at the level of a #test... method, programmers can just work with that. Actually, SUnit relies on the programmer to figure out the best granularity for both passing and failing tests. There is no need to do some analysis that goes sub-method here. </span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">***</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Anyway, what you propose here introduces a *new* feature to SUnit. It does *not fix* an existing one. :-) Regarding that proposal, I think that #shouldPass should not be called during test runs so frequently as in an #assert: call. I consider #shouldPass kind of a documentation used for tools such as in the test runner. Your proposed change in TestResult >> #unexpectedPasses renders the code practically unreadable:</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">unexpectedPasses</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">  ^ failures select: [:each | each shouldPass not]</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">What does it say? Well, somehow, a "pass" got stored in the variable "failures" and if you happen to know that #shouldPass can sort out those hidden passes... way too much magic.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">This was your initial fallacy for this proposal:</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">The Result of a Test which is tagged as an #expectedFailure IS a failure if the test passed.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">No, it is not. :-) If anything, the programmer could be happy that an expected failure passes. It is *not a failure*. Maybe something third, which we don't have yet. Serendipity? Happy accident? Not a failure.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Marcel</span></div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 27.05.2019 21:07:23 schrieb Chris Muller <asqueaker@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,
<br>
<br>This change simply fixes the display for exclusion (or inclusion)
<br>of "expectedFailures" in the list, and nothing more.  It does *not*
<br>change granularity of assert: at all.
<br>
<br>The way tests are written is unchanged, and still up to the test
<br>developer.  If you don't use #expectedFailures, you can ignore this
<br>completely.  That's the only use-case being fixed here.
<br>
<br>> 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".
<br>>
<br>> So... I do not quite agree with your statement here ... but I think you mean the right thing:
<br>>
<br>> > Expected failures should be put into their own #test.. method
<br>> > and not mixed with assertions that are expected to pass. Otherwise,
<br>> > the SUnit domain won't be able to properly express to you the state of
<br>> > those tests, as you said.
<br>>
<br>> One should not compose tests according to pass-or-not but rather following domain/project-specific reasons.
<br>
<br>Agree, and they still are composed for domain-specific reasons.  But
<br>expectedFailures are a subset *within* a domain-specific reason that
<br>not only *should* (IMO), but *need* to be separated out, because SUnit
<br>provides registration of expectedFailures ONLY at the #test... method
<br>level.
<br>
<br>So nothing is changed w.r.t. this issue you raise about mixing
<br>expectedFailures with expectedPasses.  Doing so today would result in
<br>the same ambiguity within the single test, with or without this
<br>change.  Like, what would you think if you came upon this?
<br>
<br>      testMethodRegisteredAsAnExpectedFailure
<br>            self assert: (falseExpression).
<br>            self assert: (trueExpression)
<br>
<br>The test is registered as an expectedFailure, so regardless of whether
<br>you classify that TestResult as "1 unexpected passes", "1 expected
<br>failure", either way, you have hidden information from yourself about
<br>the OTHER test in that method.  This change has nothing to do with
<br>that.
<br>
<br>> 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.
<br>
<br>expectedFailures is a feature of SUnit designed to handle use cases
<br>like the one I described.
<br>
<br>> Still not so sure about this hook, though, ... hmmm...
<br>
<br>It's not a "hook" as much as a correction to whether a particular
<br>failed assertion should be expected or not.
<br>
<br>Best,
<br>  Chris
<br></div></blockquote></div>