Pruebas unitarias: ¿Es malo tener llamadas de prueba unitaria a otras pruebas de unidad?

Question

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

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

Como 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

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

Answer 2

Creo que es una mala idea. Desea que su prueba unitaria pruebe una cosa y una sola. En lugar de crear una llamada a través de su otra prueba, haga una llamada falsa y páselo como argumento.

Answer 3

en mi humilde opinión, se debe hacer una de las siguientes:

• crear un método que devuelve una llamada válida, y lo utilizan por separado para ambas pruebas (no uno llamando a la otra)
• Mock la llamada válida para ShowCallMessageTest

Answer 4

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

Answer 5

Sí, las pruebas unitarias deben ser independientes y deben tener como objetivo probar solo una cosa (o al menos un pequeño número de cosas estrechamente relacionadas). Como acotación al margen, las llamadas a data.Expect y phone.Expect en el método de prueba están creando expectativas en lugar de llamadas de código auxiliar, que pueden hacer sus pruebas frágiles si refactoriza ...

Answer 6

de ofrecer un punto de venta libre:

Creo firmemente que la prueba de unidad bien diseñada debe depende uno del otro!

Por supuesto, eso solo tiene sentido si el marco de prueba es consciente de estas dependencias de manera que puede dejar de ejecutar la prueba dependiente cuando falla una dependencia. Aún mejor, un marco de este tipo puede pasar el dispositivo de una prueba a otra, de modo que pueda basarse en un dispositivo que crece y se extiende en lugar de reconstruirlo desde cero para cada prueba individual. Por supuesto, el almacenamiento en caché se realiza para tener cuidado. No se introducen efectos secundarios cuando más de una prueba depende del mismo ejemplo.

Implementamos esta idea en el JExample extension for JUnit. Todavía no hay un puerto C#, aunque hay puertos para Ruby y Smalltalk y ... el most recent release of PHPUnit picked up both our ideas: dependencies and fixture reuse.

PS: folks are also using it for Groovy.

Answer 7

Unidad contra módulo ... también creemos que las pruebas también deben depender de métodos reutilizables y deben probarse en una prueba de nivel de API para la integración de clases. Muchos simplemente prueban una sola clase pero muchos errores están en esa integración entre el nivel de clase. También usamos 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 revisamos una vez y funcionó muy bien).Por supuesto, cualquier cambio arquitectónico lo forzará a refactorizar las pruebas, pero al menos los cambios de diseño en el módulo no causan trabajo de refactorización de prueba (a menos que cambie el comportamiento de la API, por supuesto, implícitamente, como disparar más eventos de lo que solía hacerlo, pero eso " "Sería un cambio de API de todos modos".