Юнит-тест проходит в Debug, но зависает при запуске

Question

У меня странная проблема. У меня есть модульный тест, который постоянно застревает в режиме бега. Когда я запускаю тот же тест в Debug без точек останова, тест проходит каждый раз.

По сути, это тест подключения к сокету. Сначала я отсоединяю сокет, а затем пытаюсь переподключиться, и я пытаюсь проверить, было ли переподключение успешным.

Где-то в коде подключения, я проверяю, было ли исключение сокета. Когда это происходит, пользователю предоставляется возможность выбора в диалоговом окне, в то время как код соединения зависает через AutoResetEvent, ожидая решения.

Именно этот AutoResetEvent зависает в системе. Это должно быть обеспечено кодом в модульном тесте. Но мой вопрос: почему это происходит в режиме отладки? Есть ли что-то особенное в режиме отладки, при котором AutoResetEvents автоматически устанавливаются Visual Studio?

EDIT

Это действительно было состояние гонки. Я добавил задержку в коде после кода отключения, и теперь он работает. Но мне все еще кажется странным, что для начала есть условие гонки. Позвольте мне уточнить, вставив часть кода.

Это тестовый код:

MySystem.FindEquipment(new List<string>(1) { "192.1.1.243:28000" });
MySystem.ConstructSystem();
MySystem.IsConstructedFlag.WaitOne();
Assert.AreEqual(1, MySystem.CommunicationController.HardwareIPList.Count);

PFFrame frame1 = MySystem.Frames["0.x.x"];

Assert.IsTrue(frame1.Disconnect());
Thread.Sleep(100);
Assert.IsTrue(frame1.Connect());

Причина, по которой меня это удивляет, в том, что я жду возврата кода diconnect, прежде чем вызывать код connect. Последняя часть кода отключения выглядит следующим образом:

lclSocket.Shutdown(SocketShutdown.Both);
lclSocket.Close();
OnSocketDisconnected(new PFSocketConnectionEventArgs(ipEp));
return true;

Это потому, что методы Socket.Shutdown () и / или Socket.Close () запускают его потоки? Таким образом, даже если я возвращаю значение из моего кода отключения, сокет действительно не отключен?

Answer 1

Скорее всего из-за многопоточности. Они очень чувствительны к времени и время в сборке отладки будет другим. Вы можете использовать такой инструмент, как CHESS, чтобы исправлять ошибки.

Но сначала используйте Tools + Attach to Process. Debug + Break All, Debug + Windows + Threads и посмотрите на стеки вызовов потоков. Вы можете увидеть причину гонки или тупика.

Answer 2

Звучит как состояние гонки.Отладочный код обычно запускает много лишних вещей «под капот», и эта разница во времени, вероятно, отбрасывает ваши тесты.

Конечно, не видя код, мы действительно не можем вам сильно помочь.

Answer 3

Однажды у меня была похожая проблема, когда я сравнивал две даты и ожидал одну дату за другой, но поскольку она была выполнена так быстро, они получили одинаковую метку времени.

Answer 4

Этот тест говорит вам, что ваш код неправильно изолирован от используемой вами библиотеки сокетов.Код, который вы тестируете, не должен зависеть от определенных артефактов в этой библиотеке.Вам нужно добавить абстракцию между библиотекой сокетов, которая переводит артефакты в учетную запись.

Причина, по которой я это говорю, заключается в том, что если сокет действительно отключается 123,251 раза <100 мсек, но для отключения 123,252 раза требуется101 мсек. </p>

Я настоятельно рекомендую, чтобы почти весь ваш код модульного тестирования не использовал многопоточность.Я смотрю на потоки вызовов любого типа в моих модульных тестах как запах кода.обычно там, где я хочу видеть проблемы с многопоточностью, находится на уровне интеграции.