The test is clearly verifying a *wrong* assumption: that id -G will match posix.getgroups() which simply does not hold on OSX.

I can reproduce this reliably on a completely clean, brand new installation of 10.5: from there the only things that have been done to the box is updating to 10.5.8, and then downloading the latest XCode tools that run on Leopard.

From here, launch Terminal: leave the console open. Run id -G; then run python and look at posix.getgroups().

Now, go into System Preferences and add a new user. Don't do anything else. Don't change anything with existing user. 

In the console that was already open, do id -G again. Now run python again, and do posix.getgroups() -- those no longer match.

Clearly IMHO the assumption that the test is declaring to be an expected result simply is not true in a OSX-Unix environment. 

Yes, if I go and *edit the actual slave user* then surely I can expect failures until I restarted the buildslave. But, if by merely adding a user causes a change to the buildslaves user by no action of my own, and that causes this test to be invalid... the test itself seems to be founded on assumptions which simply are not reliably true. 

I understand disabling the test means os.getgroups() will no longer be tested on OSX: and yet, the current situation is a specific behavior of os.getgroups() is tested which is *not* actually the guaranteed behavior of that operation. 

There is at least one very easy to reproduce situation in which id -G and posix.getgroups() do not match: I don't know if there are more. But for the test to assert the truth that its only correct when they match seems to be a mistake.