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