Confusión: dejar de lado las pruebas funcionales que cubren mismo terreno que las pruebas unitarias?

Question

Estoy luchando para averiguar qué debe ser excluido de las pruebas funcionales (en mi caso, utilizando los carriles, pero supongo que del marco probablemente irrelevante).

Estoy bajo la impresión de que no debería molestarse mediante pruebas funcionales para las cosas que se enredan en las pruebas de unidad - como la comprobación de que un campo no puede tener demasiados caracteres, o que un campo no puede estar vacío. Si este es el caso, lo que sin duda contingencias deben ser ensayados con pruebas funcionales, y / o lo que es la regla de oro para dejar que otros sólo para las pruebas unitarias?

O es esta impresión incorrecta, para empezar?

He mirado este y esta pero todavía estoy en una pérdida.

Answer 1

Prueba funcional: ¿Hace las cosas marketing / usabilidad / clientes firmaron ? es decir, si su especificación establece específicamente que el cuadro de texto postal sólo permite que los códigos postales de EE.UU. válidos, entonces es probable que deben probar que en una prueba de funcionamiento.

Prueba de la unidad: ¿Hace lo que el desarrollador espera que haga? En estas pruebas se debe utilizar dobles de prueba para aislar el código de las dependencias.

Así que sí, habrá superposición de una especie.

Answer 2

Por mi parte, lo haría 'pico' a través de la funcionalidad con pruebas funcionales y no preocuparse de que abarca todo, y en lugar de centrarse en las pruebas unitarias.

Las razones:

• pruebas funcionales son lentos
• pruebas funcionales son difíciles de escribir y mantener
• pruebas funcionales sólo pueden coger dos elementos adicionales, además de las pruebas unitarias:
  • insectos GUI
  desajustes
  • transversal de capa

En general, he encontrado que no vale la pena para cubrir todo dos veces.