Share
¿Eres nuevo en Rails? ¿Nuevo en la codificación? ¿Tienes curiosidad sobre RSpec y cómo puedes comenzar a probar? Si es así, este artículo debe ser un buen punto de partida para que pueda comenzar un desarrollo basado en pruebas. Le explicará el por qué y el cómo, y le proporcionará un kit de supervivencia para su primera ola de pruebas..
¿Para qué es bueno RSpec? RSpec es muy útil en el nivel de prueba de unidad, ya que prueba los detalles más finos y la lógica de negocios de su aplicación. Eso significa probar los componentes internos como los modelos y los controladores de su aplicación. Las pruebas que cubren sus vistas o las pruebas de características que simulan flujos de usuarios más completos, como comprar un artículo, no serán el enfoque para el que se diseñó RSpec. RSpec no hace uso de un controlador web, como lo hace Capybara, por ejemplo, que simula las interacciones de un usuario con un sitio real o una representación de él..
Desarrollo guiado por pruebas (TDD), ¿cuál es el punto? Bueno, eso no es tan fácil de responder sin alimentarte de algunos clichés. Espero que esto no suene evasivo. Podría dar una respuesta rápida, pero quiero evitar enviarlo a casa con hambre después de comer solo un pequeño refrigerio. El resultado de esta pequeña serie sobre RSpec y las pruebas no solo debe proporcionarle toda la información para responder a esta pregunta, sino que también debe proporcionarle los medios y la comprensión para comenzar con las pruebas, mientras se siente un poco seguro de lo que está probando..
Los principiantes parecen tener más dificultades para entrar en RSpec y el flujo de trabajo de TDD que comenzar a volverse peligrosos con Ruby o Rails. ¿Porqué es eso? Solo puedo adivinar en este punto, pero por un lado, la literatura parece centrarse principalmente en personas que ya tienen algunas habilidades de programación en su haber, y por otro lado, aprender todo lo que implica tener una comprensión clara es un poco intimidante La curva de aprendizaje puede ser bastante empinada, supongo. Para pruebas efectivas, hay muchas partes móviles involucradas. Es mucho pedir a los novatos que acaban de comenzar a entender un marco como Rails para ver el proceso de creación de una aplicación desde la perspectiva opuesta y aprender una API completamente nueva para escribir código para su código..
Pensé en cómo abordar este "dilema" para la próxima generación de programadores que están buscando un comienzo más suave en todo esto. Esto es lo que se me ocurrió. Romperé la sintaxis más esencial para usted sin asumir mucho más que el conocimiento básico de Ruby y un poco de Rails. En lugar de cubrir todos los ángulos posibles y confundirlo hasta la muerte, repasaremos su kit básico de supervivencia e intentaremos pintar el cuadro más grande. Discutiremos el "¿Cómo?" De manera bastante verbal para no perder nuevos codificadores en el camino. La segunda parte de la ecuación explicará el "¿Por qué?"
Si tengo suerte, obtendrás una buena base para libros más avanzados mientras te sientes confiado con respecto al panorama general. Ok ahora, vamos a caminar el paseo!
Volvamos al propósito de la prueba. ¿Las pruebas son útiles para escribir aplicaciones de mejor calidad? Bueno, esto se puede debatir acaloradamente, pero en el momento en que contestaría esta pregunta con un "sí", estoy en el campo de TDD de Hipsters, supongo. Veamos por qué las pruebas proporcionan a sus aplicaciones un par de beneficios que son difíciles de ignorar:
Comprueban si su trabajo funciona según lo previsto. La validación constante de que está escribiendo un código que funciona es esencial para la salud de su aplicación y la cordura de su equipo.
Prueban cosas que no quieres probar a mano, verificaciones tediosas que podrías hacer a mano, especialmente cuando necesitas verificar esto todo el tiempo. Desea estar lo más seguro posible de que su nueva función o su nueva clase, o lo que sea, no cause ningún efecto secundario en áreas quizás imprevistas de su aplicación. Automatizar ese tipo de cosas no solo te ahorra una tonelada de tiempo, pero también hará que los escenarios de prueba sean consistentes y reproducibles. Solo eso los hace mucho más confiables que las pruebas a mano de errores..
Queremos asegurarnos de que la aplicación se comporte de cierta manera, de una manera esperada. Las pruebas pueden garantizar en gran medida que la forma en que los usuarios interactúan con su aplicación está funcionando y evitando los escenarios de errores que pudo prever. Las pruebas comprueban que su aplicación funciona de la manera en que la diseñó y que continúa funcionando después de introducir modificaciones. Esto es especialmente importante cuando su conjunto de pruebas le informa sobre escenarios fallidos sobre implementaciones de su aplicación que pueden ser antiguas y, por lo tanto, ya no están exactamente en la parte de atrás de su cerebro y no se tienen en cuenta al presentar algunas funciones nuevas. En resumen, ayuda a mantener tu aplicación saludable y evita la introducción de toneladas de errores.
Las pruebas automatizadas te hacen probar con más frecuencia. Imagínese si tiene que probar algo por 40ª vez por alguna razón. Si solo toma un poco de tiempo, ¿qué tan fácil será aburrirse y omitir el proceso por completo? Este tipo de cosas son el primer paso en una pendiente resbaladiza donde puede despedirse de un porcentaje decente de código..
Las pruebas funcionan como documentación. Eh Las especificaciones que escribes le dan a otras personas en sus equipos un punto de entrada rápido para aprender una nueva base de código y entender qué se supone que debe hacer. Escribir su código en RSpec, por ejemplo, es muy expresivo y forma bloques de código altamente legibles que cuentan una historia si se hacen correctamente. Debido a que se puede escribir de manera muy descriptiva y al mismo tiempo ser un lenguaje específico de dominio (DSL) muy conciso, RSpec golpea dos pájaros de un tiro: no está detallado en su API y le brinda todos los medios para escribir escenarios de prueba altamente comprensibles. Eso es lo que siempre me gustó y por eso nunca me entusiasmé mucho con Cucumber, que estaba resolviendo el mismo problema de una manera demasiado amigable para el cliente, creo.
Pueden minimizar la cantidad de código que escribes. En lugar de saltar como locos, probar cosas más estilo libre, la práctica de probar su código le permite escribir solo el código que es necesario para pasar sus pruebas. Sin exceso de código. Una cosa que escuchará a menudo en su futura carrera es que el mejor código es el código que no tiene que escribir o algo. ¿Por qué? Bueno, la mayoría de las veces, las soluciones más elegantes implican cantidades menores de código y, además, el código que usted no escribe, lo que podría ser innecesario, no causará ningún error en el futuro y no necesita mantenimiento. Entonces, escribir las pruebas primero, antes de escribir la implementación, le brinda un enfoque claro sobre qué problema necesita resolver a continuación. Escribir solo el código que es necesario, y no accidentalmente más, es tal vez un efecto secundario subestimado que TDD puede proporcionarle.
Tienen un efecto positivo en su diseño. Para mí, entender esta parte encendió una bombilla y me hizo apreciar realmente todo el asunto de las pruebas. Cuando escribe sus implementaciones en escenarios de prueba muy enfocados, su código probablemente resultará ser mucho más compartimentado y modular. Ya que todos somos amigos de DRY: “¡No te repitas!”, Y es el menor acoplamiento posible entre los componentes de tu aplicación, esta es una disciplina simple pero efectiva para lograr sistemas que están bien diseñados desde cero. Este aspecto es el beneficio más importante, creo. Sí, los otros también son bastante impresionantes, pero cuando las pruebas también resultan en aplicaciones cuya calidad es mejor debido a un diseño refinado, diría Jackpot!
Se reduce a dinero también. Cuando tenga una aplicación estable que sea fácil de mantener y cambiar, ahorrará bastante dinero a largo plazo. La complejidad innecesaria puede atormentar proyectos fácilmente, y la motivación no estará en su punto más alto cuando su equipo tenga que luchar contra su código porque es frágil y está mal diseñado. Un buen diseño de aplicación puede apoyar absolutamente sus objetivos comerciales y viceversa. ¿Desea introducir algunas características nuevas que son críticas para su negocio, pero está luchando constantemente contra su arquitectura porque se construyó sobre arena? Por supuesto que no, y todos hemos visto muchos ejemplos de empresas que desaparecieron rápidamente por esa razón exacta. Los buenos hábitos de prueba pueden ser una línea de defensa efectiva para tales situaciones.
Otro objetivo que es importante es con respecto a la calidad de su código. El software que escriba debe ser fácil de entender para otros desarrolladores, tanto como sea posible, al menos. Sus pruebas realmente pueden ayudar a transmitir la funcionalidad y la intención de su aplicación, y no solo a otros miembros de un equipo, sino también a su futuro yo. Si no toca una determinada sección de su código durante bastante tiempo, será realmente útil actualizar su memoria de cómo y por qué escribió una pieza de software con la documentación que proporciona una herramienta como RSpec y RSpec. esto realmente bien, excepcionalmente en realidad.
Dado que su código siempre cambiará, refactorizar su código será y siempre debe ser parte del desarrollo de su software. Y como el cambio está tan integrado en este proceso, debe asegurarse de que estos cambios no generen efectos secundarios inesperados en lugares sorprendentes. El conjunto de pruebas le brinda una red de seguridad muy unida para que se sienta más cómodo y libre de refactorear con gusto. Este aspecto, junto con los beneficios de diseño que TDD puede brindarle, es mi beneficio favorito en el que un conjunto de pruebas puede ayudarlo. Modificar y ampliar su código es un componente tan esencial de la innovación en su "producto" ya lanzado que necesita una herramienta que le brinde la mayor libertad posible con ese proceso. No estoy seguro si las personas que son críticas para escribir un extenso conjunto de pruebas están muy preocupadas por este aspecto..
Tendrás una buena oportunidad de crear cosas nuevas más rápido en etapas posteriores porque la retroalimentación del conjunto de pruebas te dará información sobre tus fallas, errores y limitaciones, mucho más rápido de lo que un humano puede probar, claro. Además, le dará la confianza de trabajar con una red de seguridad que se vuelve aún más valiosa cuanto más tiempo vaya..
En sus aplicaciones, especialmente si han crecido significativamente, desea poder confiar en su software. La cobertura del 100% del código suena mucho más dulce cuando tienes un sitio que tiene un par de años y ha sido tocado por cientos de desarrolladores. Poder confiar en el nuevo código que introduces y construir sobre eso es una de las bendiciones del desarrollo de software que el dinero no puede comprar más adelante..
rieles nuevos your_app -t
-T le permite omitir la Unidad de prueba, el marco de prueba que viene con Rails.
grupo: desarrollo,: test do gem 'rspec-rails end
haz
Después de eso necesitamos ejecutar un generador que viene con RSpec:
rieles generan rspec: instalar
create .rspec create spec create spec / spec_helper.rb create spec / rails_helper.rb
Lo que esto hace es configurar la estructura básica para sus pruebas RSpec dentro de Rails. Como se puede ver en la salida anterior, este generador inicializó un especulación Directorio con algunos archivos que necesitará más adelante. los .rspec El archivo es un archivo de configuración que no necesitaremos manipular por ahora. Solo quería hacerte saber lo que tienes delante de ti. Los otros archivos se explican por sí mismos, pero quería mencionar sus diferencias..
Accentsconagua
spec_helper.rb es para especificaciones que no dependen de Rails.rails_helper.rb, Por otro lado, es para especificaciones que sí dependen de ello..Lo que no es obvio es que uno de estos archivos debe ser requerido sobre sus archivos de especificaciones (archivos de prueba) para ejecutar sus pruebas. ¡Vamos a echar un vistazo rápido! Cuando generas un modelo a través de:
rieles generan modelo nombre dummy_model: cadena
invoke active_record create db / migrate / 20160521004127_create_dummy_models.rb create app / models / dummy_model.rb invoke rspec create spec / models / dummy_model_spec.rb
No solo Rails habrá creado el asociado. _spec.rb archivos para usted, sus especificaciones también tendrán automáticamente requiere 'rails_helper' por defecto en la parte superior de sus archivos de especificaciones. Eso significa que estás listo para ir, de inmediato.
requiere 'rails_helper' ...
Así que con esta configuración, puede probar su aplicación Rails, por ejemplo, sus modelos, y RSpec no se confundirá con las clases de modelos utilizadas en Rails. Esto es necesario que se requiera cada vez que necesite cosas como ActiveRecord, Controlador de aplicaciones y así. Así que este es su escenario normal y, por lo tanto, debería ser su primera opción lógica como principiante.
Requerir spec_helper.rb, por otro lado, generará un error si escribe pruebas que incluyan lógica de negocios desde su aplicación Rails. En ese escenario, RSpec no sabría de qué está hablando cuando quiere probar algún modelo de Rails, por ejemplo.
Tan larga historia super corta, spec_helper no carga Rails-eso es todo! Por supuesto, puedes volverte loco con las configuraciones, pero esto no es nada de lo que quiero que te preocupes ahora. Centrémonos en los conceptos básicos, cómo realizar pruebas y la sintaxis. Eso debería ser suficiente para empezar. Vamonos!
Usted está listo para ejecutar sus pruebas. RSpec requiere que sus archivos de prueba tengan un sufijo específico como _especulación para entender qué archivos ejecutar. Si usa un generador, esto no es un problema, pero si desea escribir archivos de prueba por su cuenta, así es como deben terminar. Así que tendrás que poner un archivo como your_first_test_spec.rb en tus especulación directorio.
El uso del generador para crear un modelo ficticio ya nos proporcionó spec / models / dummy_model_spec.rb. ¡No está mal! Una cosa queda por hacer antes de que las pruebas estén listas:
rake db: migrate rake db: test: prepare
Estos comandos ejecutan su migración para el modelo ficticio que generamos anteriormente y también configuran la base de datos de prueba con ese modelo. Ahora realmente ejecutamos la prueba:
rastrillo
los rastrillo comando ejecutará todas sus pruebas, la suite de prueba completa. Por lo general, debe usar este comando cuando haya finalizado alguna función y desee ejercitar todo el conjunto de pruebas.
* Pendiente: (Los errores enumerados aquí son esperados y no afectan el estado de su suite) 1) DummyModel agrega algunos ejemplos a (o elimina) / Users / vis_kid / projects / rspec-test-app / rspec-dummy / spec / models / dummy_model_spec .rb # Aún no implementado # ./spec/models/dummy_model_spec.rb:4 Terminado en 0.00083 segundos (los archivos tardaron 1.94 segundos en cargarse) 1 ejemplo, 0 fallas, 1 pendiente
¡Felicidades! Acabas de ejecutar tu primera prueba de RSpec. No es tan malo, ¿verdad? Por supuesto, esta fue una prueba ficticia para ahora, con el código de prueba ficticio generado por Rails. La versión más enfocada de ejecutar sus pruebas (en realidad tiene muchas más opciones que solo eso) es ejecutar un archivo individual, por ejemplo. Me gusta esto:
paquete exec rspec spec / models / dummy_model_spec.rb
Esto solo ejecutará un único archivo de prueba en lugar de todo el conjunto de pruebas. Con aplicaciones más grandes que dependen de una gran cantidad de archivos de prueba, esto se convertirá en un ahorro de tiempo real. Pero en términos de ahorro de tiempo y especificidad de prueba, esto es solo rascar la superficie, para ser franco. Creo que cubriremos más sobre cómo ahorrar mucho tiempo al probar en el tercer artículo de esta serie. Veamos hasta dónde llegamos!
La otra forma de ejercitar todo el conjunto de pruebas es simplemente ejecutando rspec-con o sin paquete exec, dependiendo de su configuración.
paquete exec rspec
Una cosa más que debo mencionar antes de continuar, también puede ejecutar solo un subconjunto específico de pruebas. Digamos que solo desea ejecutar todas sus pruebas para su código de modelo:
paquete exec rspec spec / modelos
Tan fácil como eso!
Recomiendo que comencemos con lo básico y que veamos algunas opciones más que RSpec ofrece en los próximos dos artículos. Echemos un vistazo a la estructura básica de una prueba y sumergámonos en aguas más avanzadas cuando tengamos esta fuera del camino.
describirEste será tu pan y mantequilla porque organiza tus especificaciones. Puede hacer referencia a cadenas o clases a sí mismos:
describe Usuario final de usuario describe 'Alguna cadena' finaliza
describir Las secciones son los componentes básicos para organizar sus pruebas en grupos lógicos y coherentes para probar. Básicamente, un ámbito para diferentes partes de su aplicación que desea probar.
describe el usuario do ... end describe el Guest do ... end describe el Attacker do ... end
Un buen consejo es ajustar su alcance aún más. Dado que algunas clases crecerán de manera significativa, no es una buena idea tener todos los métodos que desee probar para una clase en una sola. describir bloquear. Puede crear múltiples de estos bloques, por supuesto, y enfocarlos alrededor de métodos de clase o instancia. Para que su intento sea más claro, todo lo que necesita es proporcionar al nombre de la clase una cadena adicional que haga referencia al método que desea probar..
describir Agente, '#favorite_gadget' do ... end describir Agente, '#favorite_gun' do ... end describir Agent, '.gambler' do ... end
De esa manera, obtienes lo mejor de ambos mundos. Usted encapsula pruebas relacionadas en sus grupos representativos mientras mantiene las cosas enfocadas y en un tamaño decente. Para usuarios muy nuevos en Ruby land, debo mencionar que # simplemente hace referencia a un método de instancia, mientras que el punto . Está reservado para los métodos de clase. Debido a que están dentro de cadenas, no tienen implicaciones técnicas aquí, pero señalan su intención a otros desarrolladores y su futuro yo. No olvides la coma después del nombre de la clase, ¡no funcionará sin ella! En un minuto, cuando lleguemos a esperar, Te mostraré por qué este enfoque es muy conveniente..
esoDentro del alcance de describir grupos, utilizamos otro ámbito de eso bloques Estos están hechos para los ejemplos reales bajo prueba. Si quieres probar el método de instancia #favorite_gadget sobre el Agente clase, se vería así:
describe Agente, '#favorite_gadget' hacerlo 'devuelve un elemento, el gadget favorito del agente' hace ... final
La cadena que le proporcionas a la eso El bloque funciona como la documentación principal para su prueba. Dentro de él, usted especifica exactamente qué tipo de comportamiento desea o espera del método en cuestión. Mi recomendación es no exagerar y ser demasiado detallado al respecto, pero al mismo tiempo no ser demasiado críptico y confundir a otros con descripciones demasiado inteligentes..
Piense en lo que puede y debe lograr la implementación más pequeña y sencilla de esta parte del rompecabezas. Cuanto mejor escriba esta parte, mejor será la documentación general de su aplicación. No apures esta parte porque es solo una cuerda que no puede hacer ningún daño, al menos no en la superficie.
esperar()Ahora estamos llegando más al corazón de las cosas. Este método le permite verificar o falsificar la parte del sistema que desea probar. Regresemos a nuestro ejemplo anterior y veamos en acción (limitada):
describe Agente, '#favorite_gadget' hacerlo 'devuelve un elemento, el gadget favorito del agente' do expect (agent.favorite_gadget) .to eq 'Walther PPK' end end end
esperar() es la "nueva" sintaxis de aserción de RSpec. Anteriormente utilizamos debería en lugar. Una historia diferente, pero quería mencionarlo en caso de que te topes con él.. esperar() espera que le proporcione un objeto y ejerza cualquier método bajo prueba en él. Finalmente, escribes el resultado afirmado en el lado derecho..
Tienes la opción de ir por la ruta positiva o negativa con .a eq o .no_a eq por ejemplo (eq siendo corto para igual por supuesto). Siempre puede cambiar la lógica, lo que mejor se adapte a sus necesidades. Ejecutemos esta prueba sin sentido y concentrémonos en la salida que obtuvimos como resultado de nuestra configuración de prueba:
especificación rspec / models / agent_spec.rb
Fallos: 1) Agent # favorite_gadget devuelve un elemento, el gadget favorito del agente Failure / Error: expect (agent.favorite_gadget) .to eq 'Walther PPK'
Lee bastante bien, ¿no es así?? ** "Agent # favorite_gadget devuelve un artículo, y el gadget favorito de la agente"** te dice todo lo que necesitas saber:
Si hubiéramos dejado fuera la cadena que describe el método en el describir bloque, entonces la salida habría sido mucho menos clara y legible:
Describa el Agente do it 'devuelve un elemento, el gadget favorito del agente' do expect (agent.favorite_gadget). hasta el final de eq 'Walther PPK'
Fallos: 1) El agente devuelve un elemento, el gadget favorito del agente Error / Error: esperar (agent.favorite_gadget) .to eq 'Walther PPK'
Claro, hay otras formas de eludir y lidiar con esto: pasar esta información a través de su eso Bloque, por ejemplo, pero el otro enfoque es simple y funciona. Todo lo que haga fluir tu sangre, por supuesto.!
Las mejores prácticas en pruebas recomiendan que compongamos nuestras pruebas en cuatro fases distintas:
Estas cuatro fases son principalmente para facilitar la lectura y para darle a sus exámenes una estructura convencional. Es un llamado patrón de prueba, básicamente, una práctica que la comunidad aceptó ampliamente como útil y recomendada. Todo este tema de patrones es un profundo agujero de conejo, así que debes saber que voy a dejar de lado un montón para no confundir a los principiantes entre vosotros y matarlos..
Durante la configuración, prepara el escenario en el que se supone que se ejecuta la prueba. En la mayoría de los casos, esto incluirá los datos necesarios para estar listo para algún tipo de ejercicio. Pequeño consejo: no complique las cosas y configure solo la cantidad mínima necesaria para que la prueba funcione.
agent = Agent.create (nombre: 'James Bond') mission = Mission.create (nombre: 'Moonraker', estado: 'Briefed')
Esta parte realmente ejecuta lo que desea probar en esta especificación. Podría ser tan simple como:
status = mission.agent_status
Ahora verifica si se cumple o no su afirmación sobre la prueba. Así que pruebas el sistema contra tus propias expectativas..
expect (status) .not_to eq 'MIA')
El marco se encarga de los problemas de limpieza de la memoria y la base de datos, un restablecimiento, básicamente. No hay nada para que manejes en este punto. El objetivo es recuperar un estado prístino para ejecutar nuevas pruebas sin sorpresas de las que se ejecutan actualmente. Veamos lo que esto significaría en un ejemplo ficticio:
describe Agente, '#favorite_gadget' hacerlo 'devuelve un elemento, el gadget favorito del agente' do # agente de configuración = Agent.create (nombre: 'James Bond') q = Quartermaster.create (nombre: 'Q') q .technical_briefing (agent) # Ejercicio favorite_gadget = agent.favorite_gadget # Verify expect (favorite_gadget) .to eq 'Walther PPK' # El desmontaje es manejado principalmente por RSpec en sí mismo end end end
Como puede ver, en este ejemplo separamos el ejercicio y verificamos las fases claramente entre sí, mientras que en los otros ejemplos ficticios anteriores, expect (agent.favorite_gadget) .to eq 'Walther PKK, Mezclamos ambas fases juntas. Ambos son escenarios válidos y tienen su lugar. Además, las nuevas líneas ayudan a separar visualmente cómo se estructura la prueba..
Ahora viene la parte difícil, qué probar y cómo. En mi opinión, este es el aspecto de la prueba que es más confuso para los recién llegados, ¡y es comprensible! Eres nuevo en el lenguaje y el marco y, a menudo, ni siquiera sabes lo que no sabes. ¿Cómo escribes las pruebas para eso? Muy buena pregunta.
Seré muy franco, lo más probable es que no lo hagas, y no lo harás durante bastante tiempo. Sentirse cómodo con estas cosas toma un tiempo. Cuando tienes un mentor o asistes a algún campamento de entrenamiento y eso, tienes la oportunidad de aprender directamente de personas experimentadas. En ese caso, su progreso en este departamento será diferente, por supuesto..
Por otro lado, si, como tantos otros, estás aprendiendo estas cosas, la paciencia será clave. La lectura de todos los libros y artículos sin duda lo lleva en la dirección correcta, pero creo que las pruebas requieren un montón de piezas de rompecabezas más avanzadas en su lugar para que tenga sentido completo y, quizás aún más importante, antes de que se sienta cómodo con él..
La "buena" noticia es que esto no es inusual y todos hemos estado allí. La perseverancia es importante. Puedes hacer esto, no es una ciencia de cohetes, pero tomará un tiempo hasta que puedas escribir una aplicación de manera efectiva desde la perspectiva de las pruebas, quiero decir. Por ahora, siga presionando, diviértase, cometa errores, escriba aplicaciones, copie tutoriales y otras cosas hasta que se apague la bombilla..
Cuando escriba sus pruebas individuales, querrá que sus objetos hagan lo más simple posible para alcanzar sus metas. Las pruebas altamente enfocadas son realmente clave. Desea diseñar su aplicación a través de pasos muy simples y luego seguir los errores que su suite de pruebas le está proporcionando.
Solo implementa lo que sea necesario para obtener la aplicación verde. ¡No más, no menos! Esa es la parte "impulsada" en el desarrollo impulsado por pruebas. Tu trabajo está guiado por las necesidades de tus pruebas..
