Cuándo usar las pruebas unitarias?

Question

Entiendo cómo implementar pruebas unitarias, estoy luchando por saber cuándo usarlas.

Digamos que tengo una aplicación básica de recordatorios. Un usuario puede agregar/editar/eliminar recordatorios y verlos en una vista de tabla. ¿Para qué partes de la aplicación quiero configurar pruebas unitarias?

Answer 1

Suponiendo que está almacenando sus recordatorios en algún lugar, tal vez en el plist. Podría escribir una prueba de unidad para generar un objeto Recordatorio, almacenarlo, recuperar los datos y, finalmente, generar un objeto de clase Recordatorio utilizable.

Así, usted sabe varias cosas:

R: Su generación Recordatorio está trabajando

B: Su método de almacenamiento de los datos está trabajando

C: Pasar de datos a su objeto recordatorio es trabajando

Sin embargo, no debe esperar poder probar la "funcionalidad" real de su aplicación. Tales como eventos táctiles o controles de navegación. Estos deben dejarse a prueba de aceptación, que es una discusión completamente diferente.

Answer 2

Pruebe todo el código que escriba. Y si quieres ser realmente genial, write the test first. Si tiene un método en un modelo o controlador, también debe tener una prueba para ello.

Sin saber más acerca de su código, es difícil de aconsejar. Pero parece que tendría un controlador (como RemindersController) y un modelo (como Reminder). Esto sería un esquema básico Me gustaría empezar con:

• RemindersController

  • habría que añadir un nuevo recordatorio
  • debe actualizar un recordatorio existente
  • debe eliminar un recordatorio existente

• Recordatorio

  • initWithMessage:atTime: debe establecer un mensaje
  • initWithMessage:atTime: debe establecer un tiempo

Answer 3

Ideal mundo respuesta sería decir que cada línea de código que escribió debe ser probado unidad.

Pero olvidémonos de eso por un momento y regresemos al mundo real. Escribir pruebas para el código que es importante y tener otra línea de defensa lo vale. En otras palabras, ¿tiene mucho sentido probar el constructor que simplemente asigna valor a un campo? Probablemente no. ¿Vale la pena probar el analizador de prueba unitario de la cuenta de los datos de la cuenta de complejo XML que proporciona su cliente? Probablemente si.

¿De dónde viene esta diferencia?Dos razones principales:

• que es menos probable que el código constructor sufrirá cambios impredecibles (frente a tanto en evolución código analizador para reunirse con los cambiantes requerimientos/optimizaciones/refactorizaciones)
• código constructor es bastante sencillo y ya ha escrito ese código muchas veces, las pruebas pueden no ofrecerle una gran ventaja en detectar problemas; vistazo rápido a dicho código y es muy probable que sepa qué está pasando (frente al código del analizador XML complejo)

¿Por qué hacer la distinción? ¿Por qué probar esto y no eso? ¿No sería más fácil simplemente probar todo (como sugeriría mundo ideal)?

No. Debido a limitaciones de tiempo y dinero. El código de escritura toma ambos. Y solo hay cierta cantidad de dinero que alguien está dispuesto a pagar por su producto, de la misma manera que solo hay una cierta cantidad de tiempo que esperará para que se entregue. Algunas pruebas simplemente no valen la pena (de nuevo, ejemplo de código de constructor). Recuerde que las pruebas unitarias no son inmunes al diminishing returns (tener un 80% de código cubierto con pruebas puede tomar un 20% más de tiempo de desarrollo y más tarde ahorrar un 20% de tiempo en la depuración/mantenimiento, mientras que otro 10% podría consumir el doble de tiempo rinden ganancias mucho menores).

De nuevo, es probable que desee preguntar "¿Dónde está la línea?" ¿Cuándo decide "Ok, las pruebas de unidad para este código no son realmente necesarias"? Lamentablemente, este tipo de juicio viene con la experiencia. Escribir código, leer código, ver qué hacen y aprenden otros (posiblemente desarrolladores más experimentados).

Si tuviera que dar par de genéricos informa (qué unidad de prueba), los que serían:

• inicio con el código de lógica de negocio/Dominio
• asegúrese de probar todo tipo de convertidores/analizadores/calculadoras (que son bastante fáciles de probar, tienden a cambiar a menudo [debido a requisitos cambiantes o refactorizaciones] y por su naturaleza son propensos a errores)
• evite probar métodos simples de una línea, a menos que esa línea sea crucial de alguna manera
• pruebas de escritura para los insectos que descubrir (y mantenerlos!)
• no siguen los cuentos de hadas mágicas de "buen código debe tener cobertura de la prueba del 99,99%" ciegamente
• lectura questionson topic a menudo puede programmers.stackexchange.com le dará una perspectiva diferente de enfocar los problemas

Answer 4

sigo estos principios en la elección de qué tipos de pruebas para escribir y cuando:

• Enfóquese en la escritura de pruebas de extremo a extremo. Cubra más código por prueba que con pruebas unitarias y así obtener más resultados de prueba por dinero. Convierta estos en la validación automatizada de su sistema como un todo.

• Pruebas de la unidad de escritura para nuggets de lógica complicada. Las pruebas unitarias valen su peso en situaciones en las que las pruebas de extremo a extremo serían difíciles de depurar o difíciles de escribir para una cobertura de código adecuada.

• Espere hasta que la API que está probando en contra sea estable para escribir cualquier tipo de prueba. Desea evitar tener que refactorizar su implementación y sus pruebas.

Rob Ashton tiene un fine article sobre este tema, que dibujé en gran medida de articular los principios anteriormente.