2016-08-01 16 views
0

Мы используем XUnit 2.1.0 от NuGet с связанными бегунами, консолью и visualstudio, как задокументировано here под заголовком «Текущие тесты с визуальной студией» и связанный контент.CSLAs Использование WCF при запуске тестов XUnit в vs test explorer вызывает исключение олицетворения

Я также использую Visual Studio 2015 Enterprise Update 2. Единственное, что это разумно из даты является CSLA, мы на 4.0.1 (я думаю, 5 лет?)

Когда мы бежим любые тесты, требующие выборки DataPortal, тест падает, как только попытка выборки DataPortal будет отправлена ​​на сервер. WCF выбрасывает «System.ServiceModel.FaultException», в котором указано «Недопустимый токен для олицетворения - его нельзя дублировать». Важно отметить, что ни один из тестов не пытается олицетворять другого пользователя. падение происходит в любом тесте, который пытается использовать CSLA для вызова DataPortal. Мы недавно перешли от xunit 1.x к 2.x через nuget, мы использовали для запуска xunit от бегуна xunit при локальном тестировании наших тестов, но теперь это устарело. Все тесты прошли отлично, как с Gui, так и с консольным бегуном для xunit 1.x. Теперь мы должны использовать бегун визуальной студии с xunit 2.x, мы получаем это безумное исключение.

Редактировать: если вы запустите консоль xunit 2.x из-за пределов визуальной студии, тесты также прекрасны на 2.x, это визуальная студийная сторона вещей, которые не работают.

Стек след ниже:

Server stack trace: 
    at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) 
    at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) 
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) 
    at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) 
    at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) 

Exception rethrown at [0]: 
    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) 
    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) 
    at Csla.Server.Hosts.IWcfPortal.Fetch(FetchRequest request) 
    at Csla.DataPortalClient.WcfProxy.Fetch(Type objectType, Object criteria, DataPortalContext context) in D:\Dev\Insight\Trunk\Source\Lib\CSLA .NET\4.0\Source\Csla\DataPortalClient\WcfProxy.cs:line 162 
    at Csla.DataPortal.Fetch(Type objectType, Object criteria) in D:\Dev\Insight\Trunk\Source\Lib\CSLA .NET\4.0\Source\Csla\DataPortal.cs:line 245 
    at Csla.DataPortal.Fetch[T](Object criteria) in D:\Dev\Insight\Trunk\Source\Lib\CSLA .NET\4.0\Source\Csla\DataPortal.cs:line 170 

Опять же, это работает отлично, если запустить тесты из другого тестового бегуна, либо старый XUnit тест бегун или CruiseControl.Net, например (мы используем CC.Net для непрерывной интеграции и это отлично работает)

ответ

1

Я думаю, что это больше проблема с тем, как тестировщик Visual Studio устанавливает текущий пользовательский принцип. Большинство других тестовых бегунов, похоже, используют пустой GenericPrincipal, в то время как VS один, как представляется, устанавливает текущую основную роль в выданную версию текущего идентификатора Windows. Это означает, что вы получаете ошибку, которую видите, когда CSLA.NET пытается выдать себя за другое.

Этот вопрос подробно рассмотрен в этом блоге, относящейся к NUnit: http://www.ienumerable.it/2015/03/21/Setting-up-good-fixture.html

Относительно простой способ решить эту проблему с XUnit (адаптировано из приведенного выше блога) состоит в создании BeforeAfterTestAttribute, чтобы установить его в GenericPrincipal перед началом тестирования, а затем восстановить исходный принцип позже. Это гарантирует, что он будет работать с одним и тем же директором, независимо от используемого тестового бегуна.

public class RequiresGenericPrincipalAttribute : BeforeAfterTestAttribute 
{ 
    private IPrincipal _originalPrincipal; 
    public override void Before(MethodInfo methodUnderTest) 
    { 
     _originalPrincipal = System.Threading.Thread.CurrentPrincipal; 
     System.Threading.Thread.CurrentPrincipal = new GenericPrincipal(new GenericIdentity(""), new String[] { }); 
     base.Before(methodUnderTest);       
    } 

    public override void After(MethodInfo methodUnderTest) 
    { 
     base.After(methodUnderTest); 
     System.Threading.Thread.CurrentPrincipal = _originalPrincipal; 
    } 

} 
+0

Интересно, что у нас в настоящее время ~ 1200 единиц тестирования. Добавление атрибута ко всем из них будет сложным. это единственный способ заставить его работать в Visual Studio? Добавляем этот атрибут ко всем нашим тестам? Не исключено ли, что Visual Studio не захочет олицетворять себя? – Skintkingle

+0

Извините, я не знаю, как изменить пользователя, которого использует VS-бегун VS. В каком-либо из ваших тестов уже используется атрибут BeforeAfterTestAttribute, который может просто расширить его? Мог бы сделать вещи немного быстрее. – Grinden

+0

Или найдите и замените: "[Факт]" -> "[Факт, ТребуетсяGenericPrincipal]"? – Grinden

 Смежные вопросы

  • Нет связанных вопросов^_^