Кто-нибудь пробовал это?
Мне нравится moq и то, что делает pex, но я не пробовал их вместе. Думаю, в большинстве случаев я бы предпочел использовать moq, а не кротов, но мне любопытно узнать, сталкивался ли кто-нибудь с контрольно-пропускными пунктами?
Они хорошо играют?
Хотя я не пробовал, Пекс и Мок должны поладить, как старые друзья.
Хотя методы перехвата между Pex и Moq различаются (Pex использует ProfilerAPI для интерпретации инструкций MSIL, Moq использует DynamicProxy для динамического получения классов), в исходном коде Moq есть ссылки, которые предполагают, что он был разработан для предотвращения проблем с повторным входом, когда Pex мог бы вмешиваться в Moq.
Согласно оригинальному исследованию Pex, вы можете украсить свой код с атрибутами, которые контролируют, когда используется переписчик Pex.
internal static MethodCall<T> Setup<T>(Mock mock, Expression<Action<T>> expression, Func<bool> condition) where T : class
{
return PexProtector.Invoke(() =>
{
var methodCall = expression.ToMethodCall();
var method = methodCall.Method;
var args = methodCall.Arguments.ToArray();
ThrowIfNotMember(expression, method);
ThrowIfCantOverride(expression, method);
var call = new MethodCall<T>(mock, condition, expression, method, args);
var targetInterceptor = GetInterceptor(methodCall.Object, mock);
targetInterceptor.AddCall(call, SetupKind.Other);
return call;
});
}
PexProtector определяется как:
internal sealed class __ProtectAttribute : Attribute
{
}
namespace Moq
{
[__Protect]
[DebuggerStepThrough]
internal static class PexProtector
{
public static void Invoke(Action action)
{
action();
}
public static T Invoke<T>(Func<T> function)
{
return function();
}
}
}
я не заставил pex и moq работать очень хорошо вместе, хотя это было давно. Pex, похоже, заблудился в материалах Reflection.Emit/динамического прокси, которые создает moq.
я бы посоветовал взглянуть на Moles, если вам нужно издеваться над pex. это довольно хорошая насмешливая структура, и она уже связана с pex
