This page contains a list of situations and problems that Pex does not handle currently:
Pex assumes that the analyzed program is deterministic
. If it is not, Pex will go in cycles until it hits exploration bounds
Pex does not handle multithreaded programs.
(It might work in a scenario where the main thread execution is deterministic, independent of the behavior of other spawned threads.)
Native Code, .NET code that is not instrumented
Pex does not understand native code, e.g. x86 instructions called through P/Invoke, i.e. Pex does not know how to translate such calls into constraints that can be fed to the constraint solver. And even for .Net code, Pex can only analyze code it instruments
. Pex cannot instrument certain parts of mscorlib
, including the reflection library. DynamicMethod
cannot be instrumented. (The suggested workaround is to have a test mode where such methods are in types in a dynamic assembly.) Future versions of Pex will have support for some of these cases.
However, even if some methods are uninstrumented, Pex will still try to cover the instrumented code as much as possible.
At this time, we only support Pex on the X86, 32-bit .NET framework.
In principle, Pex can analyze arbitrary .NET programs, written in any .NET language.
However, the VS AddIn and the code generation are only fully implemented for C#
Pex uses an automatic constraint solver
to determine which values are relevant for the test and the program-under-test. However, the abilities of the constraint solver
are, and always will be, limited.
(Slightly) incorrect stack traces
Because Pex catches and 'rethrows' exceptions in each instrumented method, the line numbers in stack traces will not be correct. This is a (by design) limitation of the 'rethrow' instruction.
.NET 1.0 and 1.1 modules
Pex injects generic callbacks when rewriting the IL method bodies. This has a side effect that it cannot instrument v1.0 and v1.1 .net module because their metadata models do not support generics.