O teste de unidade passa na depuração, mas trava quando executado

Question

Eu tenho um problema estranho.Eu tenho um teste de unidade que fica travado no modo Run.Quando executo o mesmo teste no Debug, sem pontos de interrupção, o teste sempre passa.

Basicamente, é um teste de conexão de soquete.Primeiro desconecto um soquete e depois tento reconectar e estou tentando verificar se a reconexão foi bem-sucedida.

Em algum lugar no código de conexão, verifico se houve uma exceção de soquete.Quando isso acontece, o usuário recebe algumas opções em uma caixa de diálogo, enquanto o código de conexão fica suspenso por meio de um AutoResetEvent, aguardando uma decisão.

É este AutoResetEvent que trava o sistema.Deve ser fornecido por código no teste de unidade.Mas minha pergunta é: como isso passa no modo Debug?Existe algo especial no modo de depuração em que AutoResetEvents são definidos automaticamente pelo Visual Studio?

EDITAR

Na verdade, foi uma condição de corrida.Adicionei um atraso no código após meu código de desconexão e funciona agora.Mas ainda me parece estranho que exista uma condição de corrida para começar.Deixe-me elaborar colando parte do código.

Este é o código de teste:

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());

A razão pela qual isso me impressiona é que estou aguardando um retorno do código de desconexão antes de chamar o código de conexão.A última parte do código de desconexão é assim:

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

É porque os métodos Socket.Shutdown() e/ou Socket.Close() executam threads?Assim, mesmo que eu esteja retornando um valor do meu código de desconexão, o soquete não está realmente desconectado?

Answer 1

Parece uma condição de corrida.O código de depuração geralmente executa muitas coisas extras 'nos bastidores', e essa diferença no tempo provavelmente está prejudicando seus testes.

É claro que sem ver o código, não podemos ajudá-lo muito.

Answer 2

Provavelmente por causa de uma corrida de threading.Eles são muito sensíveis ao tempo e o tempo na compilação de depuração será diferente.Você pode usar uma ferramenta como o CHESS para exercitar bugs como esse.

Mas use Ferramentas + Anexar ao Processo primeiro.Debug + Break All, Debug + Windows + Threads e observe as pilhas de chamadas de thread.Você poderá ver a causa da corrida ou do impasse.

Answer 3

Certa vez, tive um problema semelhante em que comparei duas datas e esperava uma data após a outra, mas como foi executado tão rápido, eles receberam o mesmo carimbo de data/hora.

Answer 4

Este teste informa que seu código não está devidamente isolado da biblioteca de soquetes que você está usando.O código que você está testando não deve depender de determinados artefatos desta biblioteca.Você precisa adicionar uma abstração entre a biblioteca de soquetes que leva em conta os artefatos.

A razão pela qual digo isso é se o soquete realmente desconecta 123.251 vezes <100 mseg, mas a 123.252ª vez que a desconexão leva 101 mseg.

Eu recomendo fortemente que quase todo o seu código de teste de unidade não use threading.Vejo chamadas de threading de qualquer tipo em meus testes de unidade como um cheiro de código.normalmente, onde desejo ver problemas de threading é no nível de integração.