We've added a little filter to Pex that flags potential testability issues in your source code (at least in the context of unit testing). The idea is simple: if your code logic branches over API that depends on the environment (file system, UI, network, time, etc...), you're not doing 'pure' unit testing anymore and it could be flagged as a testability issue.

Why do we do this anyway?

The problem is that Pex is very sensitive to those issues: it cannot control the environment. Let's take a look at a simple example where we write a custom stream class with a testability issue in one of the constructor:

The constructor checks that the file exists. In order to pass that point in the program, you would actually need to create or find an actual file in the file system. You're talking to the file system, this is already integration testing.

Parameterized drama

Let's be optimistic and write a parameterized unit test that reads a file:

Pex comes back with a single test, passing null as fileName (i.e. default(string)). Since Pex does not know how the file system works, it cannot create a valid file name, and that's where the story ends.

Help is on the way

To help you diagnose these issues, we've added specialized logging flags. Pex shows hints in the issue notification area:

Clicking on that event will give you additional important data: which API was called and the stacktrace at the time of the call :)