En la vida de cada desarrollador, llega un momento en que piensa en crear un componente de prueba para su creación. Mejoraré, en la vida de todo buen desarrollador. Cuando eres un junior y no tienes ninguna responsabilidad especial, tienes derecho a muchos errores y puedes corregirlos en cualquier momento. Usted no es responsable del producto que crea y no tiene la motivación para dedicar un minuto adicional a verificar el código generado. "Nada, esta jamba no se puede reproducir", "esta cosa parece funcionar", "bueno, al menos, hace lo que debe ser": si quiere superar el nivel de programador, tendrá que negar cada uno de estos pensamientos.
Con el desarrollo de su propia experiencia de programación, tiene nuevos clientes cada vez más geniales / grandes. Incluso estará encantado con algunos (de todos, si tiene suerte): las personas son buenas y pagan generosamente, y no son quisquillosas con los problemas que surgen. Veamos uno de estos casos simples (muy simple, pero lo principal que está detrás de esto) de crear un controlador de formulario de un programador que no conoce la molestia.
Entonces, la tarea simple ha llegado: escribir un controlador de formulario. El objetivo es aceptar solicitudes de clientes para la compra de ladrillos. El cliente es grande, se dedica a grandes entregas de ladrillos a granel (por ejemplo, por una cantidad de más de 500,000 rublos para sentir al menos un cierto nivel de responsabilidad por lo que está sucediendo). La competencia es feroz: los clientes pueden acudir rápidamente al proveedor de ladrillos si no responden en un día.
Se le dijo a nuestro programador que es necesario guardar los datos del cliente del formulario: el nombre del representante, el número de teléfono, el nombre de la empresa del cliente, el volumen del pedido y un campo opcional de descripción del pedido. Cerebro de Porakinin, se creó rápidamente una forma simple con campos estándar para el frente del sitio:
Los datos del formulario se envían mediante una solicitud AJAX, sin volver a cargar la página. Además, el programador asume el diseño del controlador de formularios y necesita hacer frente a una tarea bastante trivial: agregar entradas para el nuevo cliente a la tabla de pedidos ya existente y enviar al cliente un correo electrónico con una notificación sobre el nuevo cliente.
El formulario funciona, los datos se guardan con éxito, el cliente está satisfecho. Pero, de repente, una llamada enojada proviene del cliente: "dicen que ya llegó el pedido: la compañía millonaria quiere comprarme todos los ladrillos, pero el número de teléfono no proviene del formulario y ¿cómo puedo contactarlos ahora?" ¡Mañana encontrarán otro proveedor! ¿Cómo es eso que hiciste? Es tu culpa ... " El cliente se desgarra, menos nervios, menos confianza y menos respeto. La situación es extremadamente estándar para un junior: la ausencia de validación y prueba de los datos entrantes del formulario. La primera tarea (validación) se resuelve extremadamente simple agregando reglas de validación:
De ahora en adelante, el cliente del sitio solo indicará los datos correctos que necesitamos para su posterior procesamiento. En la misma etapa, el desarrollador tiene la idea de probar el código para evitar una situación tan incómoda. Por ejemplo, probar el campo del apellido se verá así (para simplificar el ejemplo básico, la protección csrf está deshabilitada):
Sabemos que en ausencia de este campo, el código debe devolver una respuesta con un error y un estado de 400 prescrito por nosotros. Tales métodos de prueba se prescriben para cada situación específica (o validación de campo específica, todo depende de las tareas y la imaginación del desarrollador).
¿Pero hay un método de desarrollo diferente al de "Lo hice, pero ahora lo comprobaré"? Primero escribimos el código, tropezamos con las jambas de ejecución, lo arreglamos y luego recordamos las pruebas. Este enfoque puede ir de lado para nosotros y nuestro cliente, dado el cliente multimillonario perdido (aunque en teoría, todos esos clientes lo estarían). Y luego me hice una pregunta: ¿qué pasa si comenzamos la lógica de crear una aplicación desde el extremo opuesto? Primero, hacemos demandas al "ejecutor" y luego hacemos que cumpla con estos requisitos. Probémoslo.
Dejamos la tarea como antes, solo cambiamos el enfoque. Necesitamos escribir un controlador de formulario con los campos fio, phone, corp, quant y content. El resultado de una ejecución exitosa es el estado 200, agregando un campo a Orden con el mensaje "ok" y devolviendo datos en el registro ingresado, otras opciones: estado 400 y una lista de errores.
En primer lugar, necesitamos escribir un método de prueba para completar válidamente los datos del formulario:
Luego, cree la ruta necesaria y el método del controlador (mientras está vacío). Si ejecutamos la prueba ahora, se espera obtener un error. Validar datos válidos no es todo lo que necesitamos. Ahora comenzamos a probar la validación del campo de formulario. Determinamos qué campos son obligatorios: fio, phone, corp, quant y agregamos un método de verificación (el comentario es opcional):
El controlador de formularios simplemente tendrá que verificar los datos entrantes fio, phone, corp, quant. Como eliminamos todos los campos obligatorios de la solicitud, se debe devolver un error en cada uno de ellos. En el caso de que al menos uno de ellos no esté presente, el problema de ejecución. Si lo desea, puede agregar una marca de verificación para el mensaje, como se hizo anteriormente (marque "ok").
Emitimos una verificación de la longitud mínima de los campos fio, phone y corp (se realizará una verificación similar para la longitud máxima y los caracteres no válidos en estos campos).
Nuestros cheques están en su lugar, puede ejecutar y verificar
Perfecto Nuestra aplicación se bloqueó en 5 de 5 pruebas. Nuestro objetivo adicional es pasar por métodos de prueba que establecen valores no válidos en los campos y forman reglas de validación para los datos entrantes. La lógica es algo como esto: el campo fio no puede estar vacío; longitud no inferior a 3 y no superior a 120; Esta es una cadena con el conjunto de caracteres permitidos en el nombre (letras, guiones, guiones). El resultado de esta lógica en todos los campos:
En respuesta a un archivo, se ha agregado una lista de errores que corresponden a cada campo "problema". Esto nos ayudará a verificar los campos específicos para la validación (afirmar JsonStructure en el archivo de prueba). A continuación, agregamos el método de validación y obtenemos la versión final:
Y finalmente, podemos verificar cómo funciona nuestro script en las pruebas (recuerdo, hubo 5 fallas en 5 pruebas).
Como puede ver, todas las pruebas pasaron con éxito y solo se ingresó una entrada en la base de datos (ya que solo un método se configuró para funcionar correctamente).
¿Cuáles son los hallazgos? El desarrollo de aplicaciones, comenzando con las pruebas, es una mejor opción que la escritura habitual de funcionalidad. La necesidad de recibir del método solo lo que se necesita es comparable con la disciplina del ejército: el código hace exactamente lo que se requiere de él, no un paso al costado. Sin embargo, este enfoque tiene un lado negativo (aunque controvertido): el hecho es que escribir funcionalidades adicionales (que son pruebas) también toma parte del tiempo asignado para el desarrollo del proyecto. En cuanto a mí, la elección es clara: un buen programador debe escribir pruebas, y comenzar con la funcionalidad de prueba ayuda a escribir un proyecto confiable y que funcione bien. Intentaré usarlo en algo menos trivial.