Konsola nunitowa "nie można załadować pliku lub zestawu" przy użyciu MySolution.sln

Question

Mam użyć nunit-console do uruchomienia wszystkich testów w moim rozwiązaniu.

Zrobiłem to:

c:\some\path>nunit-console-x86.exe MySolution.sln 
NUnit-Console version 2.6.2.12296 
Copyright (C) 2002-2012 Charlie Poole. 
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov. 
Copyright (C) 2000-2002 Philip Craig. 
All Rights Reserved. 

Runtime Environment - 
    OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1 
    CLR Version: 2.0.50727.5466 (Net 3.5) 

ProcessModel: Default DomainUsage: Default 
Execution Runtime: net-3.5 
Could not load file or assembly 'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. 

Więc postanowiłem spróbować nunit-x86.exe zrobiłem File > Open Project > MySolution.sln i dostał to:

--------------------------- 
NUnit 
--------------------------- 
Test load failed! 

System.IO.FileNotFoundException : Could not load file or assembly 
'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral, 
PublicKeyToken=null' or one of its dependencies. The system cannot 
find the file specified. 

For further information, use the Exception Details menu item. 
--------------------------- 
OK 
--------------------------- 

The exception can be found here

co się dzieje i jak zrobić Naprawię to? (bez konieczności utrzymywania plik MySolution.nunit)

Więcej informacji

• MyNamespace.Administration nie jest nawet jedną z bibliotek DLL, który zawiera testy, co oznacza, że ​​nunit zawiedzie próbuje załadować go szukać testy do uruchomienia. Wiedząc o tym, zredagowałem plik stworzony przez nunit-x86.exe (MySolution.nunit) i usunąłem wszystkie biblioteki dll, które nie miały testów. Rzeczywiście, testy działają (zarówno w trybie GUI, jak i konsoli). Jest to dla mnie nie do przyjęcia, ponieważ oznaczałoby to, że muszę przechowywać kolejny plik konfiguracyjny. Nunit wspierający pliki .sln miał tego uniknąć.
• Moje testy zakończą grzywny za pomocą TestDriven.NET (ale naprawdę trzeba uruchomić je przy użyciu nunit-console)
• Mam spojrzał na this answer ale nie mogę zrozumieć, co mówi Log Viewer Fusion. Czy opublikowanie tego dziennika pomogłoby? Montaż wiązania Log Viewer, wymienia 3 pliki tworzone:
  • nunit-agent-X86.exe, ten wydaje się być trudny do znalezienia MyNamespace.Administration.dll/EXE inside the nunit directories
  • Tests_24398275 X2 - jeden szuka nunit.core w moich folderach projektowych i inne szukające unit.core.interfaces w moich folderach projektu. Nie zwracałbym na nich uwagi, ponieważ pojawiają się one również w moim ręcznie edytowanym projekcie .nunit).
• (za komentarzem andreistera) Problem wydaje się być związany z samym projektem/zespołem, a nie z metodą tworzenia. Jeśli utworzę projekt .nunit i spróbuję dodać do niego MyNamespace.Administration (używając "Dodaj zestaw ..." lub "Dodaj projekt VS ..."), to się nie powiedzie.
• Zadzwoń pod nunit-console-x86 somepath/bin/Debug/MyNamespace.Administration.dll bezpośrednio działa.

Answer 1

Niestety, nawet po opublikowaniu na nunit-discuss group nie mogłem znaleźć odpowiedniego rozwiązania dla tego problemu.

Grupa nunit-discuss potwierdziła, że ​​moje testy zawiodły z powodu posiadania zależności o jeden poziom wyżej.

Zrobiłem jednak akceptowalne obejście.

Ponieważ wywoływanie .dll s bezpośrednio nie miało takich samych problemów. Mogłem to zrobić z globusami, ale jestem na windows ... ale mam zainstalowane git bash.

Korzystając z moim nieco sztywnej struktury projektu i nazewnictwo udało mi się to zrobić:

"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll' 

Należy pamiętać, że skorzystał z mojego konwencji nazewnictwa. Jest to bardzo ważne, aby zmniejszyć liczbę argumentów.

Gdy zrobiłem nunit-console-x86 MysolutionFolder/*/*/bin/Debug/*.dll zamiast , dostałem błąd od nunit-console-x86, mówiąc: Bad file number. Poza tym jest to szybsze, jeśli tylko dostarczę odpowiednie pliki.

Jeśli masz nowszą wersję bash (4.0+, myślę), można zamiast tego użyć następującego polecenia (Zwróć uwagę na użycie **):

"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/**/bin/Debug/*.Tests.dll' 

Który jest krótsze i bardziej liberalne na struktura projektu.

Answer 2

przeksięgowanie moją odpowiedź na NUnit-dyskutować:

NUnit cechą załadunku VS rozwiązań jest naprawdę dość ograniczona i przeznaczone są do pracy z prostych projektów lub jako szybki sposób utworzyć plik projektu NUnit - czyli załadować rozwiązanie i zapisz jako projekt NUnit, a następnie zmodyfikuj plik XML, który jest tworzony. Ponieważ format pliku rozwiązania nie wskazuje, które pliki są testami, NUnit próbuje załadować każdy projekt, aby sprawdzić, czy zawiera on jakiekolwiek testy. (Jest to to samo, co Visual Studio 2012 i później, gdy używasz okna eksploratora testowego, btw.)

Jak sugerujesz, myślę, że dany zespół nie może zostać załadowany z powodu posiadania zależności o jeden poziom wyżej. Podczas ładowania pliku rozwiązania VS lub pliku projektu NUnit, NUnit ustawia bazę aplikacji na katalog zawierający rozwiązanie lub projekt. Dlatego działa projekt NUnit o jeden poziom wyżej.

Intencją projektantów w tego rodzaju sytuacji jest utworzenie pliku projektu NUnit. Rozumiem, że jest to trochę niewygodne, ponieważ daje ci kolejny plik konfiguracyjny do utrzymania. Jestem otwarty na sugestie dotyczące korzystania z globów w wierszu poleceń lub w pliku projektu. Wszelkie takie zmiany prawdopodobnie przejdą do kolejnej ważnej aktualizacji, NUnit 3.0.