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