I've just run into this; actually I ran into it last week, but it took me until yesterday to find a workaround (programmatically overriding Ant's basedir, eww), and then today finding the real cause. I now know way more about Ant's and Maven's innards than I wanted to!
I'm trying to test an Ant task by running an Ant build file from a subdirectory. So I have a test case/class which extends org.apache.tools.ant.BuildFileTest and passes it the name of an Ant build file. BuildFileTest, which extends JUnit's TestCase, is part of the test suite for Ant itself and its built-in tasks.
The problem is, the system property "basedir" set by Surefire (the base directory of the Maven project) conflicts with Ant, because the "basedir" attribute of a build.xml (base directory of an Ant project) can be overridden via the system property "basedir". A classic namespace collision. Both equally at fault, I suppose, but Ant /was/ there first!
Thus when my Ant task test looks for files using paths which relative to the the subdirectory, it can't find them because basedir is now pointing to the root of the Maven project, not the basedir of the Ant test build.
As Dan suggested, it is possible to unset basedir in the test class(es), but that seems like the wrong approach. I'd prefer that my test cases were independent of the test environment, without adding in environment-specific workarounds.
What is the expected use of Surefire's basedir system property, within a JUnit test? Who uses it? Perhaps the property could be renamed, perhaps as "maven.basedir". A test case which used this property would be Maven-dependent; might as well be explicit about it. (Or better still, avoid such dependencies entirely!)