Tengo algunas aplicaciones que me gustaría volver atrás y crear retroactivamente un conjunto de pruebas (RSpec & Cucumber), pero es un poco desalentador comenzar ese proceso.Rieles: ¿buen proceso para agregar pruebas retroactivamente?
¿Cuál sería su proceso para volver a una aplicación existente y construir un conjunto de pruebas para ella?
Recientemente comencé a abordar la adición de pruebas a un montón de código viejo, y lo que encontré inmensamente útil es rcov (no me molesto con el rcov rails plugin y simplemente cd para probar y ejecutar un pequeño script de shell que ejecuta rcov con las exclusiones correctas y abre el informe si todas las pruebas pasan). Luego, comencé a abordar las que estaban más cerca de la cobertura del 100% y solo trabajando en el porcentajes poco a poco. Es un progreso mucho más medible que, "Uf, ¿por dónde empiezo añadiendo pruebas para esto?"
¡Gran sugerencia y realmente útil! – Shpigford
He estado haciendo mucho de esto últimamente para proyectos de clientes. Los bloques más grandes para mí parecen ser el uso desenfrenado de javascript en línea con o sin RJS. [Nota al margen: hay una forma correcta y una incorrecta de hacer AJAX, y la mayoría de la gente está haciendo Doing It Wrong ™.] Normalmente uso pepino en gran medida con un poco de rspec para pruebas de unidades extrañas.
Las variables a considerar son diversas, pero un buen lugar para comenzar es con unas pocas pruebas unitarias para sus modelos. Cree algunas fábricas y pruebe sus validaciones, junto con cualquier comportamiento personalizado que crea que necesita pruebas.
Si no te gusta eso o si ya tienes un conjunto de pruebas unitarias y quieres agregar integración, la siguiente pregunta es hasta qué punto estás haciendo un montón de inline javascript o RJS. Si su aplicación es muy "ajaxy", tendrá que comenzar con el controlador de selenio para pepino, que es lento como melaza en febrero, pero lo hará bien. Una vez que tenga un conjunto de pruebas que cubran la funcionalidad completa (o incluso solo las cosas importantes) para su aplicación, comenzaría a refactorizar el javascript para que funcione de forma discreta.
Otra dirección que podría ir sería construir rspecs adicionales para sus controladores y vistas, pero realmente no me gusta este patrón que se está metiendo probar la aplicación en lugar de la funcionalidad.
Lo importante a recordar es que no todo tiene que suceder de la noche a la mañana. Analice sus flujos de trabajo (por ejemplo, inicie sesión, realice la tarea A, realice la tarea B, etc.) y determine cuáles cubren el 80% de los casos de uso típicos. Pon a prueba los primeros. Luego use algo como metric_fu o simplemente rcov (o cualquier otra herramienta de cobertura) y encuentre áreas de su código que sean densas en lógica y no probadas. Me gusta metric_fu para esto porque el conjunto de herramientas que ejecuta puede proporcionarle ambas piezas de información.
Me gustaría ir y agregar pruebas de alto nivel (pepino) primero. Esto le dará la confianza de que el comportamiento no cambiará desapercibido. No iría y agregaría pruebas de rspec (o tal vez solo algunos pocos) porque probablemente también desee refactorizar mucho.
Luego, ejecute metrics. MetricFu recientemente obtuvo una métrica llamada "HotSpots", que combinará otras métricas y lo dirigirá a los puntos problemáticos más grandes en el código. Estos lugares suelen ser también los más críticos para su aplicación. Solucione los problemas lo suficiente para que sean legibles y tendrá una buena idea de qué se trata. No te vayas por la borda todavía.
Luego, para cada nueva característica que agregará, agregue las especificaciones y limpie el código con el que está interactuando. Así que prueba y refactoriza las dependencias de las nuevas funciones, pero no vayas más allá. Hazlo en trozos pequeños o perderás la esperanza rápidamente.
estoy un poco fuera de tema aquí, pero de todos modos ...
creo que la unidad de pruebas de modelos en los carriles (3 como mínimo) es una especie de valor ... o sea especialmente cuando el código está escrito , entonces no estás haciendo TDD. ¿Quieres probar tu validación? Por qué ? Simplemente lea el código y usted mismo descubrirá los errores. Digo que los rieles proporcionan (en algún lugar) una sintaxis humana tal que sería una lástima probarla en una unidad.
En mi opinión, tal sintaxis es ella misma una especificación. Entonces, ¿por qué escribir prueba?
Y para que quede claro: No, no estoy diciendo que las pruebas sean inútiles todo el tiempo. No estoy trabajando en una agencia web al azar ...: p
Entiendo su punto de vista. Aún así, si no está seguro, agregue las especificaciones. Si es el comportamiento de su aplicación, debe probarlo. Y los modelos son la parte principal de su lógica comercial, por lo que yo diría que la mayoría de las pruebas/especificaciones unitarias serían para los modelos. – iain
De hecho. Para resumir mi punto: si la sintaxis del lenguaje parece legible para el negocio, entonces ¿por qué pruebas? –
Para protegerse de las regresiones, donde el código adicional que escribe rompe la funcionalidad anterior. A menos que planee volver a leer totalmente su código cada vez que realice un cambio ... – Gareth
+1 porque me estaba haciendo la misma pregunta –