Forzar MSTest utilizar un solo hilo

Question

Dado este conjunto de prueba:

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

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

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

¿Hay alguna manera de obligar a MSTest a ejecutarlas con un solo hilo?

Answer 1

He luchado durante interminables horas para hacer que MSTest se ejecute en un único modo enhebrado en un proyecto grande que hizo un uso intensivo de nhibernate y no es seguro (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, según mi leal saber y entender, no es posible ejecutar MSTest en un único modo de subproceso.

Answer 2

Si bien es una respuesta de salida de policía, en realidad lo aliento a hacer que su código sea seguro para subprocesos. El comportamiento de MSTest es garantizar el aislamiento como lo ha señalado Richard. 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.

Answer 3

Tratamos de 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 unas 10.000 en una ejecución hay una buena probabilidad de una colisión a menos que el autor del código de una prueba se asegure de que sus datos iniciales sean únicos (es decir, no use las mismas claves primarias que otra). 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 4

He resuelto este problema con 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 

Answer 5

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 6

probé un poco de un enfoque diferente, ya que el subyacente El problema 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 llamó a 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 puede ejecutarse en múltiples núcleos e hilos ...