¿Hay demasiadas afirmaciones en esta prueba unitaria?

Question

¿Hay demasiadas afirmaciones en esta prueba de una unidad?

[Fact] 
public void Send_sends_an_email_message() { 
    using (var server = new MockSmtpServer()) { 
     server.Start(); 
     using (var client = new EmailClient("localhost")) { 
      string from = "john.doe@example.com"; 
      IEnumerable<string> to = new[] { "jane.doe@example.com" }; 
      string subject = "Test"; 
      string body = "Test."; 
      client.Send(from, to, subject, body); 
      var session = server.Sessions.FirstOrDefault(); 
      Assert.NotNull(session); 
      var message = session.Messages.FirstOrDefault(); 
      Assert.NotNull(message); 
      Assert.NotNull(message.From); 
      Assert.Equal(message.From.Address, "john.doe@example.com"); 
      Assert.NotNull(message.To); 
      var recipient = message.To.FirstOrDefault(); 
      Assert.NotNull(recipient); 
      Assert.Equal(recipient.Address, "jane.doe@example.com"); 
      Assert.Equal(message.Subject, "Test"); 
      Assert.Equal(message.Body, "Test."); 
     } 
    } 
} 

No creo que este código requiera ninguna explicación, pero si lo hace hágamelo saber.

Answer 1

Intento mantener mis UnitTests bastante pequeños y probar una cosa a la vez. Así que probablemente haga pruebas de partes distintas en pruebas separadas, p.

• sendWillSendAnEmail,
• fromContainsSenderAddress,
• toContainsRecipientAddress,
• mailBodyContainsMailMessage,
• mailContainsSubject

Answer 2

No, en general, cuantas más afirmaciones, mejor. Un error común en las pruebas unitarias no es lo suficientemente explícito.

Su prueba es muy explícita y legible. Me gustan especialmente las afirmaciones sobre null. Es una buena práctica porque hace que interpretar una falla de prueba sea extremadamente simple.

La única forma en que puede tener demasiadas afirmaciones es si afirma exactamente lo mismo más de una vez, lo cual no está haciendo.

Answer 3

veo ningún problema particular con su afirma, pero si desea limpiar su código, puede cambiar

var session = server.Sessions.FirstOrDefault(); 
Assert.NotNull(session); 

en

var session = server.Sessions.First(); 

First() lanzará una excepción de todos modos, así que por simplemente cambiando tu código obtienes el beneficio que la afirmación te traería sin tanto código. Hay otros lugares donde puedes hacer cambios similares también.

Pero como regla general, no damos nada por sentado en las pruebas unitarias, ¡y eso significa muchas afirmaciones!

Answer 4

Depende de las normas a las que se adhiere, pero generalmente digo que sí, que tiene demasiadas afirmaciones en esa prueba.

Muchas personas afirman que una sola prueba debe tener una sola afirmación; Creo que puede ser un poco exagerado, pero ciertamente creo que es apropiado tener una prueba unitaria para un solo "pedazo" de funcionalidad; estás por todos lados con tus afirmaciones. La prueba es muy grande; dividirlo en varias pruebas diferentes.

Answer 5

Creo que la pregunta es, ¿los assert() d valores cambian de forma independiente? Si cambian de forma independiente, deben probarse en diferentes pruebas que varían las condiciones relacionadas con cada afirmación.

Sin embargo, si tiene un solo código que está generando un correo electrónico con todos esos campos, entonces es apropiado probar todo eso en una prueba.

Ahora la prueba es algo difícil de leer. Es posible que desee envolver esos asertos en un método descriptivo de ayuda. No me molestaría con eso hasta que encuentre que el mismo método de ayuda podría ser útil en otro lugar.

Answer 6

Creo que es demasiado grande.

Cuando tiene un montón de pruebas más pequeñas, puede obtener "localización de defectos": con solo ejecutar todas las pruebas, puede ver exactamente dónde está el problema. Con tantas afirmaciones como las que tiene actualmente (y sin mensajes de afirmación) probablemente tenga que iniciar un depurador para averiguarlo. Recuerde que probablemente terminará teniendo cientos si no miles de pruebas, y si un grupo de ellas falla, no quiere tener que depurar cada una para ver por qué.

Además, cualquier afirmación que falle temprano en la prueba significa que las afirmaciones posteriores no se ejecutarán. Cuando se separan en pruebas individuales, se verifica cada afirmación. Esto es una especie de compensación; muchas de esas afirmaciones probablemente están relacionadas y fallarán al mismo tiempo, por lo que tendrá cinco pruebas rojas en lugar de una. Pero trabajo desde la premisa de que hay más información mejor, así que preferiría tener esas cinco pruebas y saber que las cinco afirmaciones fallaron.

Answer 7

Sus muchas afirmaciones afirmativas son un indicador de cuánta lógica tiene en las pruebas unitarias. Tendrás que mantener tus pruebas unitarias como el código normal. Es mejor dedicar tiempo a la programación defensiva y a la programación por contrato que a las pruebas de unidades de código.

Answer 8

Tal vez pueda crear una nueva clase de correo electrónico que acepte todos esos parámetros en su constructor predeterminado.

Y luego puede lanzar una excepción en caso de que el usuario pase un parámetro no válido.

Y en su unidad de prueba

Send_sends_an_email_message

puede agregar el afirma que los cheques igualdades sólo que en lugar de comprobar contra los nulos.

Quizás pueda crear 2 correos electrónicos en una prueba y hacer la igualdad afirma para ambas instancias.

Answer 9

¡Sí, tienes demasiadas afirmaciones en tu código! Además, la declaración de afirmación debe ser solo uno por método de prueba. El uso de muchas afirmaciones puede ser el olor del código que está probando más de una cosa. Además, existe la posibilidad de que alguien pueda agregar una nueva afirmación en su prueba en lugar de escribir otra. ¿Y cómo puedes entender cómo terminaron tus otros asertos cuando falló el primero?

También pueden parecido interesante este post: https://timetocode.wordpress.com/2016/06/01/zen-of-unit-testing/