visual studio - tutorial - Obligando a MSTest a usar un solo hilo

visual studio code shortcuts

Question

Dado este accesorio de prueba:

[TestClass]
public class MSTestThreads
{
[TestMethod]
public void Test1()
{
Trace.WriteLine(Thread.CurrentThread.ManagedThreadId);
}
[TestMethod]
public void Test2()
{
Trace.WriteLine(Thread.CurrentThread.ManagedThreadId);
}
}

Ejecutar la prueba con MSTest a través de Visual Studio o línea de comando imprime dos números de hilos diferentes (sin embargo, se ejecutan secuencialmente de todos modos).

¿Hay una manera de forzar a MSTest a ejecutarlos usando un solo hilo?

Answer 1

He luchado durante horas interminables para hacer que MSTest se ejecute en un modo de subproceso único en un proyecto grande que hizo un uso intensivo de nHibernate y no es seguro para subprocesos (no es un problema, simplemente no lo es) ISession .

Terminamos más tiempo escribiendo código para admitir la naturaleza de subprocesos múltiples de MSTest porque, hasta donde sé, y lo mejor de mi equipo, no es posible ejecutar MSTest en un solo modo de subprocesos.

Answer 2

Nos esforzamos por distinguir las pruebas aisladas entre sí. Muchos de ellos logran esto configurando el estado de una base de datos y luego restaurándola. Aunque la mayoría de las pruebas configuran datos diferentes, con aproximadamente 10,000 en una ejecución, existe una posibilidad justa de colisión a menos que el autor del código de la prueba se asegure de que sus datos iniciales sean únicos (es decir, no use las mismas claves primarias que otras). prueba haciendo algo similar). Esto es, francamente, inmanejable, y obtenemos fallas de prueba ocasionales que pasan la segunda vez. Estoy bastante seguro de que esto es causado por colisiones que se evitarían ejecutando las pruebas de forma estrictamente secuencial.

Answer 3

Probé un enfoque diferente, porque el problema subyacente es que los nombres de las tuberías son el problema. Así que hice un fakePipe, lo derivé del que uso en el programa. Y nombró la tubería con el nombre de las pruebas.

[TestClass]
public class PipeCommunicationContractTests {
private PipeDummy pipe;
/// <summary>
///Gets or sets the test context which provides
///information about and functionality for the current test run.
///</summary>
public TestContext TestContext { get; set; }
[TestInitialize]
public void TestInitialize() {
pipe = new PipeDummy(TestContext.TestName);
pipe.Start();
}
[TestCleanup]
public void TestCleanup() {
{
pipe.Stop();
pipe = null;
}
...
[TestMethod]
public void CallXxOnPipeExpectResult(){
var result = pipe.Xx();
Assert.AreEqual("Result",result);
}
}

Parece ser un poco más rápido, ya que podemos ejecutar en múltiples núcleos y subprocesos ...

Answer 4

Puede derivar su clase de prueba de

public class LinearTest
{
private static readonly object SyncRoot = new object();
[TestInitialize]
public void Initialize()
{
Monitor.Enter(SyncRoot);
}
[TestCleanup]
public void Cleanup()
{
Monitor.Exit(SyncRoot);
}
}

Answer 5

Resolví este problema con el bloqueo:

public static class IntegrationTestsSynchronization
{
public static readonly object LockObject = new object();
}

[TestClass]
public class ATestCaseClass
{
[TestInitialize]
public void TestInitialize()
{
Monitor.Enter(IntegrationTestsSynchronization.LockObject);
}
[TestCleanup]
public void TestCleanup()
{
Monitor.Exit(IntegrationTestsSynchronization.LockObject);
}
//test methods
}
// possibly other test cases

Por supuesto, esto puede extraerse a una clase de prueba base y reutilizarse.

Answer 6

Si bien es una respuesta de salida de policía, realmente lo alentaría a hacer que su código sea seguro para subprocesos. El comportamiento de MSTest es asegurar el aislamiento como Richard ha señalado. Al enfrentar problemas con las pruebas de su unidad, está demostrando que podría haber problemas en el futuro.

Puede ignorarlos, usar NUnit o tratar con ellos y continuar usando MSTest.