c# - tipos - pruebas unitarias php

Prueba de unidad: ¿es una mala forma que la prueba de unidad llame a otras pruebas de unidad?

Question

Tengo una prueba de unidad llamada TestMakeAValidCall() . Prueba mi aplicación de teléfono haciendo una llamada válida.

Estoy a punto de escribir otra prueba llamada TestShowCallMessage() que necesita tener una llamada válida realizada para la prueba. ¿Es una mala forma simplemente llamar a TestMakeAValidCall() en esa prueba?

Para referencia, esta es mi prueba TestMakeAValidCall() .

    [TestMethod]
    public void TestMakeAValidCall()
    {
       //Arrange
        phone.InCall = false;
        phone.CurrentNumber = "";
        // Stub the call to the database
        data.Expect(x => x.GetWhiteListData()).
            Return(FillTestObjects.GetSingleEntryWhiteList());
        // Get some bogus data
        string phoneNumber = FillTestObjects.GetSingleEntryWhiteList().
            First().PhoneNumber;
        // Stub th call to MakeCall() so that it looks as if a call was made.
        phone.Expect(x => x.MakeCall(phoneNumber)).
            WhenCalled(invocation =>
                       {
                           phone.CurrentNumber = phoneNumber;
                           phone.InCall = true;
                       });

       //Act
        // Select the phone number
        deviceControlForm.SelectedNumber = phoneNumber;
        // Press the call button to make a call.
        deviceMediator.CallButtonPressed();

       //Assert
        Assert.IsTrue(phone.InCall);
        Assert.IsTrue(phone.CurrentNumber == phoneNumber);
    }

Answer 1

Creo que es una mala idea. Usted quiere que su prueba de unidad pruebe una cosa y una sola cosa. En lugar de crear una llamada a través de su otra prueba, simule una llamada y pásela como un argumento.

Answer 2

En mi humilde opinión, debe hacer uno de los siguientes:

• Cree un método que devuelva una llamada válida y utilícelo por separado para ambas pruebas (no una que llame a la otra)
• Simula la llamada válida para el ShowCallMessageTest

Answer 3

Para ofrecer un punto contrario:

¡Creo firmemente que la prueba de unidad bien diseñada debe depender la una de la otra!

Por supuesto, eso solo tiene sentido si el marco de prueba es consciente de estas dependencias, por lo que puede detener la ejecución de la prueba dependiente cuando falla una dependencia. Aún mejor, un marco de este tipo puede pasar el dispositivo de prueba a prueba, de manera que se puede construir sobre un dispositivo de crecimiento y extensión en lugar de reconstruirlo desde cero para cada prueba individual. Por supuesto, el almacenamiento en caché se realiza para evitar que se introduzcan efectos secundarios cuando más de una prueba depende del mismo ejemplo.

Implementamos esta idea en la extensión JExample para JUnit . Aún no hay un puerto C #, aunque hay puertos para Ruby y Smalltalk y ... la versión más reciente de PHPUnit recogió nuestras dos ideas: dependencias y reutilización de dispositivos .

PD: la gente también lo está utilizando para Groovy .

Answer 4

Refactorice la configuración a otro método y llame a ese método desde ambas pruebas. Las pruebas no deben llamar a otras pruebas.

Answer 5

Sí, las pruebas unitarias deben ser separadas y deben apuntar a probar solo una cosa (o al menos una pequeña cantidad de cosas estrechamente relacionadas). Además, las llamadas a data.Expect y phone.Expect en su método de prueba están creando expectativas en lugar de llamadas de stub, lo que puede hacer que sus pruebas sean frágiles si usted refactoriza ...

Answer 6

Una prueba de unidad debe probar una unidad / función de su código por definición. Hacer que llame a otras pruebas unitarias hace que pruebe más de una unidad. Lo rompo en pruebas individuales.

Answer 7

Una unidad frente a un módulo ... también creemos que las pruebas deben depender de métodos reutilizables y que deben probarse a nivel de API. Integración de clases. Muchos solo prueban una clase individual, pero muchos errores están en esa integración entre el nivel de clase. También utilizamos Verifydesign para garantizar que la API no dependa de la implementación. Esto le permite refactorizar todo el componente / módulo sin tocar una prueba (y lo hicimos una vez y funcionó muy bien). Por supuesto, cualquier cambio en la arquitectura obliga a refactorizar las pruebas, pero al menos los cambios de diseño en el módulo no causan el trabajo de refactor de prueba (a menos que cambie el comportamiento de la api, por supuesto implícitamente como disparar más eventos de los que solía hacer, pero eso " sería "un cambio de API de todos modos).