Taking a look at the follwing, existing methods, everything seems to be already there:

TestResult >> #failures
TestResult >> #failureCount
TestResult >> #defects

There is no need to change anything. The message #failures correctly combines #unexpectedFailures and #unexpectedPasses. The message #defects combines #errors and #failures.

The use of the instance variables failures, errors, and passes is an implementation detail that can stay is it is for this use case.

@Chris: Why did it matter that those instance variables refer to tests the current way?

Best,
Marcel
Am 30.05.2019 01:25:14 schrieb David T. Lewis <lewis at mail.msen.com>:
On Wed, May 29, 2019 at 04:07:11PM -0500, Chris Muller wrote:
> > > Would you mind helping me out with one then?
> >
> > What are the challenges exactly you are trying to tackle here? Can you provide more context?
>
> I had to think about this -- I think,
> abstractly, the case comes up when something that "should" (or "should
> not") work, is in conflict with whether we want it or expect it to
> work. We can look as close as the trunk image for a good example.
>
> SocketTest>>#testSocketReuse
>
> This test is expected to fail on Windows. For sake of argument, let's
> pretend that the reason is because there is a security hole in Windows
> (surely not! ;) ) and so we, as developers of Squeak, commented out
> windows support in the VM because we *absolutely positively want this
> to fail on Windows* until we're sure the coast is clear.

This is a test for platform-specific functions that are known to be
unavailable when running on a Windows VM. We expect it to fail when
running on Windows. SocketTest>>expectedFailures makes this explicit.

If Squeak is running on a Windows VM, this test will fail, and the
failure is expected. It is an expected failure.

That seems reasonable to me.

If it is not clear what an "expected failure" is, then a good method
comment in TestCase>>expectedFailures might help. And if we cannot
agree on the method comment, then it's a sure bet that we should not
be fiddling with the implementation.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190531/1317704b/attachment.html>