2014-10-23 7 views
5

Mamy projekt testowy NUnit z 1000 testów. Projekt zawiera test komponentów wysokiego poziomu głównie dla niestandardowego sterowania WPF. Proces badania często nie powiedzie się na naszym serwerze kompilacji (TeamCity) z:Proces testowy NUnit często kończy się niepowodzeniem ze sterowaniem WPF

InvalidOperationException "przechowywania LocalDataStoreSlot został uwolniony"

System.LocalDataStore.GetData (System.LocalDataStoreSlot gniazda)

mscorlib.dll mscorlib! .dll! System.Threading.Thread.GetData (System.LocalDataStoreSlot gniazdo)

WindowsBase.dll! System.Windows.Interop.ComponentDispatcher.CurrentThreadData.get() ...

Testy zawierają atrybuty [RequSTA], Window.Show(), operacje dyspozytorskie itp., Więc zdecydowanie nie jest to zwykły test jednostkowy.

Niepowodzenie wygląda zupełnie przypadkowo, mamy wersje, w których występuje z 80% szansą, jednak przez większość czasu tak się nie dzieje. Absolutnie tajemnicze, czasami proste zmiany w kodzie produkcyjnym - podobnie jak zmiana stylów w kodzie xaml - powodują awarie, a następnie zmiana w kodzie produkcyjnym to naprawia.

Ta konkretna przypadkowa porażka sprawia, że ​​nasz zespół programistów jest czasami bardzo zmartwiony, nasz rozszerzony system kompilacji jest poważnie utrudniony przez tę porażkę.

Rzadko możemy odtworzyć go lokalnie uruchamiając projekt za pomocą narzędzia nunit-console.exe.

Czy kiedykolwiek widzieliście taki proces testowy? Wszelkie sugestie dotyczące rozwiązania tego problemu byłyby bardzo cenne.

Dzięki

+0

Mamy ten sam problem na naszych serwerach kompilacji, ale przy użyciu Jenkins. Prawie nigdy nie widziane lokalnie na urządzeniach dla programistów. Przeprowadzamy również wiele testów elementów WPF, które tak naprawdę nie są testami jednostkowymi. Przez chwilę teoria była taka, że ​​problem ten pojawił się z nie kończącymi się dyspozytorami robiącymi dziwne rzeczy, ale teraz wydaje się, że mamy to nawet przy właściwym zabiciu każdego uruchomionego dyspozytora. Czy udało ci się to rozwiązać? Jakieś aktualizacje? – Niclas

+0

wciąż walczymy z tym. Nie ma jeszcze rozwiązania. – pappati

Odpowiedz

1

My spotkaliśmy dokładnie ten sam problem w naszym środowisku (Jenkins, Windows 8, NUnit 2.6.3).

Te środki naprawiły to za nas.

  1. Upewnij się, że NUnit nie działa w środowisku .NET 3.5 lub wcześniejszym. Ten post wyjaśnia, w jaki sposób.
  2. Obejście awarii NUnit po wyłączeniu przy użyciu opcji wiersza poleceń NUnit runner /nothread. Jeśli używasz MS Build Community Tasks, musisz ustawić atrybut TestInNewThread zadania NUnit na false.

Kilka podstawowych informacji dotyczących rodzaju awarii znajduje się w tym MSDN forum thread. Ostatecznie należy to naprawić w NUnit.

Powiązane problemy