Консольный бегун NUnit 3 не может утверждать, что коллекция заказана

Я запускаю сборку CI с использованием Travis CI. Я запускаю тесты NUnit через файл nunit3-console.exe. У меня есть несколько тестов, которые пытаются подтвердить, что коллекция упорядочена:

[Test]
public void FeatsAreSorted()
{
    var result = controller.Generate() as JsonResult;
    dynamic data = result.Data;
    Assert.That(data.character.Ability.Feats, Is.Ordered.By("Name"));
}

Когда я запускаю этот тест в Visual Studio, он проходит нормально. Однако, когда я запускаю тест через nunit3-console.exe в Travis CI, я получаю следующую ошибку:

1) Error : DNDGenSite.Tests.Unit.Controllers.CharacterControllerTests.GenerateSortsCharacterFeats
Microsoft.CSharp.RuntimeBinder.RuntimeBinderException : `NUnit.Framework.Assert.That<System.Linq.OrderedEnumerable<CharacterGen.Common.Abilities.Feats.Feat,string>>(System.Linq.OrderedEnumerable<CharacterGen.Common.Abilities.Feats.Feat,string>, NUnit.Framework.Constraints.IResolveConstraint)' is inaccessible due to its protection level

Это мой .travis.yml:

language: csharp
solution: DNDGenSite.sln
install:
  - nuget restore DNDGenSite.sln
  - nuget install NUnit.Runners -OutputDirectory testrunner
  - nuget install Chutzpah -OutputDirectory testrunner
script:
  - xbuild DNDGenSite.sln /p:TargetFrameworkVersion="v4.5.1" /p:Configuration=Release
  - mono ./testrunner/NUnit.Console.*/tools/nunit3-console.exe ./Tests/bin/Release/DNDGenSite.Tests.dll
  - mono ./testrunner/Chutzpah.*/tools/chutzpah.console.exe ./Tests/Unit/Scripts

Какие-нибудь мысли?

ОБНОВЛЕНИЕ: если я запускаю тесты в git bash, все проходит правильно, как в режимах сборки Debug, так и в Release. Таким образом, среда, в которой Travis CI создает средство запуска консоли, отличается от среды.


person cidthecoatrack    schedule 15.02.2016    source источник
comment
Проверьте разницу версий двух компиляторов. Проверьте документы NUnit.Framework.Assert.That... на предмет защищенности и изменений к ним. Сообщите об ошибке, если это необходимо,   -  person набиячлэвэли    schedule 15.02.2016
comment
Я не совсем понимаю, что вы имеете в виду.   -  person cidthecoatrack    schedule 16.02.2016
comment
Проверьте различия версий (compiler --version) и посмотрите, что изменилось. Проверьте документацию о том, как изменился спецификатор доступа, так как у вас может быть устаревшая библиотека.   -  person набиячлэвэли    schedule 16.02.2016
comment
Но вот что мне интересно - он отлично работает, когда его запускает Visual Studio, поэтому он должен быть одной и той же скомпилированной версией между VS и когда Travis CI компилирует ее.   -  person cidthecoatrack    schedule 16.02.2016
comment
Вероятно, нет, вы предполагаете, что (а) нет ошибок и (б) версия компилятора Travis не устарела, что, вероятно, так и есть.   -  person набиячлэвэли    schedule 16.02.2016
comment
а) Если бы была ошибка, она бы обнаружилась при запуске теста в Visual Studio, а этого не происходит, б) даже если версия компилятора travis устарела, при восстановлении пакета будет установлена ​​последняя версия NUnit - это то, что я использую. Таким образом, компилятор Travis на самом деле не манипулирует кодом, выдающим ошибку. Возможно, я что-то упустил в вашем объяснении.   -  person cidthecoatrack    schedule 18.02.2016


Ответы (1)


В конце концов я обнаружил, что утверждение порядка объекта dynamic вызывало ошибку в Travis. Если вместо этого я убедился, что он равен другому объекту, и проверил свойства этого объекта, тест проходит нормально.

person cidthecoatrack    schedule 29.04.2016