La teoría establece que podría comenzar con el ciclo BDD y pasar al ciclo TDD. Agregue una especificación de característica, luego agregue una especificación de controlador, una especificación de vista, una especificación de modelo, implemente cada pieza, luego comience nuevamente. Esa es la ruta segura.
La mayoría de la gente no los sigue. La experiencia le dirá el nivel de comodidad sobre la cantidad de pruebas que debe hacer. Si no sabe, hágalos todos, la pila completa. No tiene derecho a elegir hasta que haya pasado varios meses en un proyecto y ahora tenga que refactorizar, eliminar piezas, reescribir algunas secciones y debe sentir el dolor de las partes que omitió las especificaciones o las partes donde escribió especificaciones frágiles y ahora pasa más tiempo ajustando las especificaciones y luego haciendo la implementación en sí.
No existe el “orden de importancia” o las “especificaciones de funciones que duplican las especificaciones de los controladores”. No hay reglas estrictas escritas en piedra. Hay niveles de confort. Por ejemplo, si usted es el único desarrollador de su propio proyecto personal de mascotas y está absolutamente seguro de que nadie más tocará ese código y no tiene ganas de agregar especificaciones, entonces no lo haga. Especialmente si es algo que sabes está a un tiro de distancia. Ahora, los niveles de prueba cambian cuanto más sepa que no se quedará para siempre en el proyecto, más sabrá que habrá más desarrolladores haciendo otros módulos que eventualmente se integrarán con los suyos.
- ¿Podría una aplicación con un backend Parse manejar un lanzamiento exitoso?
- ¿Es bueno usar Node.js + Express o Play Framework para construir un sitio de venta de fotos como Shutterstock o Getty Images?
- ¿Por qué una aplicación nativa es mejor que una aplicación web?
- ¿Cuáles son las características más importantes para una experiencia de usuario óptima de una página web en dispositivos móviles?
- ¿Cuál es la mejor manera de hacer una aplicación de Android? Si esta es mi primera aplicación de Android, ¿cuánto tiempo llevará?
En la práctica, la mayoría de las personas agregarán especificaciones de características para las características más complicadas o importantes (sí, evite hacer las especificaciones de características de boilerplace para meras pantallas de inicio de sesión o pantallas de “olvidé mi contraseña”, podría, pero no es prioridad). Agregue especificaciones para todos sus modelos y clases relacionadas, como Trabajadores, Servicios, Decoradores / Presentadores, etc. Agregue especificaciones para el enrutamiento para asegurarse de que la navegación no se interrumpa. Agregue especificaciones de controlador para asegurarse de que sus vistas reciban las variables de instancia correctas que necesitarán para representar las vistas y agregue especificaciones de características para asegurarse de que la navegación entre controladores / páginas funcione. No son duplicaciones: las especificaciones del controlador verifican los parámetros HTTP de entrada y las variables de instancia resultantes para las vistas y eso es todo. La especificación de características prueba los casos de uso reales desde el punto de vista de los usuarios. Las especificaciones de Modelo, Controlador, Vista prueban la matriz de entradas / salidas para cada clase, son técnicas. Las especificaciones de funciones están centradas en el usuario.
Comience con la directriz Better Spec para Rspec básica (Better Specs {rspec Guidelines with ruby}).
