Not sure if it's fixable, but I think it's important to at least make the issue known.
There is a possibility that running fastest will say a test has passed when it shouldn't. The only cause I have been able to create this issue with is having two classes with the same name but separate namespaces used in a test - e.g. My\First\FileSystem and My\Second\FileSystem. Both of which have the same number & type of arguments in their constructors.
Ordinarily, when running tests as standard, this will immediately be picked up and cause an error. It's possible when running fastest that these two classes will never be around each other at any time during testing, and the test will pass. Tests pass -> Missed it in a peer review -> Deploy to staging -> balls.
Not sure if it's fixable, but I think it's important to at least make the issue known.
There is a possibility that running fastest will say a test has passed when it shouldn't. The only cause I have been able to create this issue with is having two classes with the same name but separate namespaces used in a test - e.g.
My\First\FileSystemandMy\Second\FileSystem. Both of which have the same number & type of arguments in their constructors.Ordinarily, when running tests as standard, this will immediately be picked up and cause an error. It's possible when running fastest that these two classes will never be around each other at any time during testing, and the test will pass. Tests pass -> Missed it in a peer review -> Deploy to staging -> balls.