> >  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 why it's not necessarily serendipitous for it to unknowingly
start "passing".  We want to know, and stay in control.

On the flip side, the situatin could be that we want it to work, but
due to core design of Windows, it won't ever be supported, so we know
it'll _never_ pass.

But that doesn't mean we want to write code that says

    isWindows
            ifTrue: [ should raise ]
            ifFalse: [ self assert: ... ]

because "should raise" expresses we think it "should", when wish it
didn't.  We feel it "should work" but it simply doesn't.

For either story, our current implementation of expectedFailures
prevents Windows users from participating in a proper SUnit
experience.








 - Chris