VS2012 & TFS2012 Unit Test głównych problemów

Question

Używamy VS2012 i TFS2012 i zapisujemy testy jednostkowe dla naszego kodu. Chcemy zgłosić pokrycia kodu, a także za pomocą plików .config w naszych testów jednostkowych dla AppSettings testowych, a także niektóre inne ustawienia logowania, ustawienia biblioteki MS Enterprise itd. Itp

---

App.config nie działa w nowym szkielecie testowym

Nowe ramy testowe SM powinny być świetne, ale dla mnie nie jest wcale taki wspaniały. Jak mam ustawić podstawową konfigurację w plikach konfiguracyjnych, kiedy nowy framework nie używa już plików konfiguracyjnych?

Mieliśmy problem z mieszanych bibliotek DLL tryb i znalazłem poprawkę: dodawanie

<startup useLegacyV2RuntimeActivationPolicy="true"> 

do app.config. Ale to nie zadziałało w naszym projekcie testów jednostkowych. Nie ma już plików konfiguracyjnych. Wyszukiwanie w internecie pojawił się roztworem

'Problems with .Net 2.0 Mixed Mode Assemblies inside Visual Studio .Net 4.5 Test Projects'

Oznacza to, edytując plik Visual Studio 11 sama w katalogu Program Files, a nie świetne rozwiązanie myślę ....

I co powiesz na podstawowe składy? Jak mam to ustawić?

---

Nie używaj plik .testSettings

pomocą pliku stare .testsettings również nie jest zalecane przez MS, ponieważ posiadał wówczas stare ramy test jest stosowany. A jeśli używam pliku .testsettings, nie mogę ustawić pokrycia kodu w mojej usłudze kompilacji tfs2012.

Inną kwestią jest to, że mamy kod, który potrzebuje dll (system.data.sqlite.dll), ale tylko w czasie wykonywania kod testowy jednostki potrzebuje tej biblioteki dll. Więc odniesienie nie jest potrzebne. Naprawiliśmy to za pomocą zakładki Wdrożenie w pliku testsettings. Ale w nowej strukturze nie powinieneś używać pliku testsettings. Masz atrybut [deploymentitem], jeśli potrzebujesz plików. Jednak atrybut deploymentitem może być używany tylko w metodzie testowania, a nie w metodzie [testinitialize] lub [assemblyinitialize]. Ale nasz kod wymaga biblioteki dll w metodzie [testinitialize]. Więc nie ma sposobu, aby uzyskać dll w miejscu.

Po prostu skopiuj go za pomocą File.Copy w metodzie [assemblyinitialize] (lub testinitialize) nie działa.

Dodanie pliku dll jako pliku do projektu i ustawienie "Kopiuj do katalogu wyjściowego" na "Kopiuj zawsze", jak wspomniano w 'Configuring Unit Tests by using a .runsettings File' również nie działa.

Rozwiązanie (naprawdę nie świetne) polega na dodaniu biblioteki DLL w celach informacyjnych, a następnie utworzeniu instancji klasy i uniknięciu jej. W ten sposób biblioteka DLL jest potrzebna, w przeciwnym razie nie jest budowana, a zatem dll wdroży się do odpowiednich katalogów.

---

jak rozwiązać mój problem ??? - Chcę użyć plików konfiguracyjnych w moim teście jednostki. - Chcę wdrożyć niektóre pliki, które są potrzebne w metodach "assemblyinitialise" i/lub "classinitialize". - Chcę, aby zasięg kodu na mojej nocnej kompilacji TFS2012 był włączony.

Answer 1

a) App.config nie działa w nowej strukturze testowej

To powinno nadal działać. W tym przypadku brakuje mi tego, że ten plik .config nie jest kopiowany z biblioteką testową. Czy mógłbyś ustawić to jako element wdrażania i spróbować ponownie?

b) nie wolno używać .testSettings złożyć

• .testsettings i pokrycia kodu. Ustawienie zasięgu kodu za pomocą pliku .testsettings jest nadal obsługiwane w kompilacji VS 2012. Wystarczy wybrać MSTest 2010 testową biegacza i określ plik .testsettings w definicji kompilacji

Jeśli nie masz nic oprócz ustawień pokrycia kodu w .testsettings plik i można łatwo migrować do listwy 2012 testowym i wybierz „umożliwiają pokrycie kodu” w rozwijanym przedmiotów

• kopiowania pliku wymaganych testów initalize można to zrobić za pomocą pliku .testsettings lub może masz post-build zadanie kopiowania plików. Jest to całkiem proste i nie ma wpływu na nic innego. Używanie "copy to output directory = copy always" działa. Wypróbuj za pomocą przykładowego rozwiązania i zobacz, czy możesz zawęzić wyjaśnienie, dlaczego to nie działa w Twojej konfiguracji.