Pruebas RSpec para principiantes, Parte 1

() translation by (you can also view the original English article)

¿Eres nuevo en Rails? ¿Nuevo en la codificación? ¿Curioso acerca de RSpec y cómo puede comenzar a hacer pruebas? Si es así, este artículo debe ser un buen punto de partida para que puedas entrar en el Desarrollo guiado por pruebas. Se le explicará el por qué y el cómo, y le dará un kit de supervivencia para ir a su primera juerga de pruebas.

Temas

¿Cuál es el punto?
¿RSpec?
Primeros pasos
Ejecución de pruebas
Sintaxis básica
Cuatro fases de pruebas
Lo difícil de hacer Pruebas

¿Cuál es el punto?

¿Para qué sirve RSpec? RSpec es muy útil en el nivel de prueba de unidad, probando los detalles más finos y la lógica de negocio de su aplicación. Eso significa probar los internos como modelos y controladores de tu aplicación. Las pruebas que cubren sus vistas o pruebas de características que simulan flujos de usuario más completos, como comprar un artículo, no son pensados para RSpec. RSpec no hace uso de un controlador web—como hace Capybara, por ejemplo—que simula las interacciones de un usuario con un sitio real o una representación del mismo.

Desarrollo guiado por pruebas (TDD), ¿cuál es el punto? Bueno, eso no es tan fácil de responder sin darle algunos clichés. Espero que esto no suene evasivo. Podría proporcionar una respuesta rápida, pero quiero evitar enviarlo a casa hambriento después de tener sólo un pequeño aperitivo. El resultado de esta pequeña serie acerca de RSpec y las pruebas no sólo debe darle toda la información para responderte a esta pregunta a ti mismo, sino también proporcionar los medios y la comprensión para empezar con las pruebas, sintiéndose un poco confiado ya sobre la cosa de prueba.

Los principiantes parecen tener un tiempo más difícil entrar en RSpec y el flujo de trabajo TDD que empezar a ponerse peligroso con Ruby o Rails. ¿Porqué es eso? Sólo puedo adivinar en este momento, pero por un lado, la literatura parece centrarse principalmente en las personas que ya tienen algunas habilidades de programación en su haber, y por otro lado, el aprendizaje de todas las cosas que se trata de tener una comprensión clara es Un poco intimidante. La curva de aprendizaje puede ser bastante empinada, supongo. Para una prueba eficaz, hay un montón de partes móviles involucrados. Es mucho pedir a los principiantes que han empezado a entender un marco como Rails para ver el proceso de construcció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 codificadores que sólo están buscando un comienzo más suave en todo esto. Esto es lo que me ocurrió. Voy a romper la sintaxis más esencial para ti 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 con la muerte, revisaremos su kit básico de supervivencia e intentaremos pintar el cuadro más amplio. Vamos a discutir el "¿Cómo?" Más bien verbalmente a fin de no perder nuevos codificadores en el camino. La segunda parte de la ecuación explicará el "¿Por qué?"

Si tengo suerte, saldrás con una buena base para libros más avanzados mientras te sientes confiado acerca de la imagen más grande. Bien, ahora, ¡vamos a caminar la caminata!

Beneficios y Tales

Volvamos al propósito de las pruebas. ¿Es útil la prueba para escribir aplicaciones de mejor calidad? Bueno, esto puede ser acaloradamente debatido, pero por el momento yo respondería a esta pregunta con un sí—estoy en el campo TDD hipster, 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. Constantemente la validación de que está escribiendo código que funciona es esencial para la salud de su aplicación y la cordura de su equipo.

Prueban cosas que no quieren probar a mano, comprobaciones tediosas que podrían hacer a mano, especialmente cuando tendrían que comprobar esto todo el tiempo. Quiere estar lo más seguro posible que su nueva función o su nueva clase o lo que sea no causa efectos secundarios en áreas quizás completamente imprevistas de su aplicación. La automatización de ese tipo de cosas no sólo le ahorra un montón de tiempo, pero también hará que los escenarios de prueba coherentes y reproducibles. Eso solo los hace mucho más confiables que las pruebas a mano que son propensas a errores .

Queremos asegurarnos de que la aplicación se comporte de cierta manera, de una manera esperada. Las pruebas pueden asegurarse de que el modo en que los usuarios interactúan con la aplicación está funcionando y de evitar los escenarios de errores que pudieron prever. Las pruebas comprueban que su aplicación funciona de la manera en que la diseñó—y que sigue funcionando después de introducir modificaciones. Esto es especialmente importante cuando su suite de pruebas le informa acerca de los escenarios fallidos sobre las implementaciones de su aplicación que pueden ser viejas y por lo tanto no exactamente en la parte posterior de su cerebro y no se considera mientras se introduce alguna nueva funcionalidad. En resumen, ayuda a mantener su aplicación saludable y evita la introducción de toneladas de errores.

La automatización de pruebas hace que realmente hagas pruebas con mayor frecuencia. Imagínese si tiene que probar algo por 40 vez por alguna razón. Si es sólo 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 se puede besar adiós a un porcentaje decente de código de cobertura.

Las pruebas funcionan como documentación. ¿Huh? Las especificaciones que escribes dan a otras personas de tus equipos un punto de entrada rápida para aprender una nueva base de código y entender lo que 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 hace correctamente. Debido a que se puede escribir de forma muy descriptiva al mismo tiempo que es un lenguaje específico del dominio (DSL) muy conciso, RSpec golpea dos pájaros con una sola piedra: no ser detallado en su API y proporcionarle todos los medios para escribir escenarios de prueba altamente comprensibles. Eso es lo que siempre me gustó y por qué nunca me encariñe con Cucumber, que estaba solucionando el mismo problema de una manera excesivamente amigable con el cliente, creo.

Pueden minimizar la cantidad de código que escribes. En lugar de jugar como un loco, probar cosas más libres, la práctica de guiar tu código por pruebas te permite escribir sólo el código necesario para pasar tus pruebas. Nada de exceso de código. Una cosa que oirás a menudo en su carrera futura es que el mejor código es el código que no tienes que escribir o algo asi. ¿Por qué? Bueno, lo más a menudo posible, las soluciones más elegantes implican menos cantidades de código y también, el código que usted no escribe—que podría ser innecesario—no causará ningún error futuro y no necesita ser mantenido. Así que escribir las pruebas primero, antes de escribir la implementación, le da un enfoque claro en el problema que debe resolver a continuación. Escribir sólo 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í, la comprensión de esta parte se convirtió en una bombilla y me hizo realmente apreciar toda la prueba. Cuando escribe sus implementaciones en escenarios de prueba muy enfocados, su código probablemente resultará ser mucho más compartimentado y modular. Dado que todos somos amigos de DRY—"¡No te repitas!"—y con tan poco acoplamiento entre los componentes de su aplicación como sea posible, esta es una disciplina simple pero eficaz para lograr sistemas que están bien diseñados desde el principio. Este aspecto es el beneficio más importante, creo. Sí, los otros son bastante impresionantes también, pero cuando las pruebas también resultan en aplicaciones cuya calidad es mejor debido a un diseño refinado, yo diría !Victoria!

Se reduce a dinero también. Cuando tienes una aplicación estable que es fácil de mantener y fácil de cambiar, ahorrará un poco de dinero a largo plazo. La complejidad innecesaria puede obstaculizar los proyectos fácilmente, y la motivación no estará en un máximo histórico cuando su equipo tiene que luchar contra su código porque es frágil y mal diseñado. Un buen diseño de aplicaciones puede soportar sus objetivos de negocio—y viceversa. ¿Quieres introducir algunas características nuevas que son críticas para tu negocio, pero estás luchando constantemente contra tu arquitectura porque fue construida sobre la arena? Por supuesto que no, y todos hemos visto muchos ejemplos de negocios que desaparecieron rápidamente por esa razón. Los buenos hábitos de prueba pueden ser una línea eficaz de la defensa para tales situaciones.

Otro objetivo que es importante es con respecto a la calidad de su propio código. El software que escriba debe ser fácil de entender para otros desarrolladores—tanto como sea posible, al menos. Sus exámenes pueden ayudar a transmitir la funcionalidad y la intención de su aplicación—y no sólo a otros miembros de un equipo, sino también a su futuro yo. Si no toca una cierta sección de su código durante bastante tiempo, realmente será útil para refrescar su memoria de cómo y por qué escribió un pedazo de software con la documentación que proporciona una herramienta como RSpec—y RSpec hace esto realmente bien, excepcionalmente en realidad.

Dado que su código siempre cambiará, refactorizar su código y siempre debe ser parte del desarrollo de su software. Y puesto que el cambio es tan metido en este proceso, es necesario asegurarse de que estos cambios no generan efectos secundarios inesperados en lugares sorprendentes. La suite de pruebas le ofrece una red de seguridad muy ajustada para sentirse más cómodo y libre de refactorizar con gusto. Este aspecto, junto a los beneficios de diseño TDD puede proporcionarle, es mi beneficio favorito una suite de prueba puede ayudarle con. La modificación y ampliación de su código es un componente esencial de la innovación en su "producto" ya lanzado que necesita una herramienta que le da tanta libertad como sea posible con ese proceso. No estoy seguro de si las personas que son críticos de escribir una extensa suite de pruebas están muy preocupados por este aspecto.

Tendrás una buena oportunidad de crear nuevas cosas más rápido en etapas posteriores, porque los comentarios del conjunto de pruebas te dará información sobre tus fallos, errores y limitaciones, mucho más rápido de lo que un humano puede probar, por supuesto. 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 se vaya.

En sus aplicaciones, especialmente si han crecido significativamente, desea poder confiar en su software. 100% de cobertura de código suena mucho más dulce cuando tienes un sitio que es un par de años y tocado por cientos de desarrolladores. Ser capaz de confiar en el nuevo código que introduce y la construcción en la parte superior de que es una de las maravillas de desarrollo de software que el dinero no puede comprar más adelante.

Primeros pasos

Terminal

1	rails new your_app -T

-T permite omitir la unidad de prueba, el marco de pruebas que viene con Rails.

Gemfile

1	group :development, :test do
2	gem 'rspec-rails'
3	end

Terminal

bundle

Después de eso necesitamos ejecutar un generador que viene con RSpec:

Terminal

1	rails generate rspec:install

Salida

1	create .rspec
2	create spec
3	create spec/spec_helper.rb
4	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 directorio spec con unos pocos archivos que necesitará más tarde. El archivo .rspec es un archivo de configuración que no necesitaremos manipular por ahora. Sólo quería decirte lo que tienes delante. Los otros archivos son auto-explicativos, pero quería mencionar sus diferencias.

spec_helper.rb es para especificaciones que no dependen de Rails.
rails_helper.rb, por otro lado, es para las especificaciones que sí dependen de él.

Lo que no es obvio es que uno de estos archivos debe ser requerido encima de sus archivos de especificaciones (archivos de prueba) para ejecutar sus pruebas. !Vamos a echar un vistazo rápido! Cuando genera un modelo mediante:

Terminal

1	rails generate model dummy_model name:string

Salida

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 sólo Rails ha creado los archivos _spec.rb asociados para ti, sus especificaciones también tendrá automáticamente require 'rails_helper' por defecto en la parte superior de sus archivos de especificaciones. Eso significa que estás listo usarlo, de inmediato.

spec/models/dummy_model_spec.rb

1	require 'rails_helper'
2
3	...

Así que con esta configuración, puede probar su aplicación Rails, por ejemplo, sus modelos, y RSpec no se confundirá sobre las clases de modelo utilizadas en Rails. Esto es necesario para requerir siempre que necesite cosas como ActiveRecord, ApplicationController y así sucesivamente. Así que este es su escenario normal y por lo tanto debe ser su primera elección lógica como principiante.

Requerir spec_helper.rb, por otro lado, lanzará un error si escribe pruebas que incluyen lógica de negocios de su aplicación Rails. En ese escenario, RSpec no sabría de lo que está hablando cuando quiere probar algún modelo de Rails, por ejemplo.

Tan larga historia super acortada, spec_helper no carga Rails—¡eso es todo! Por supuesto, puedes jugar con las configuraciones, pero esto no es nada de lo que se debe preocupar por ahora. Centrémonos en lo básico, cómo ejecutar pruebas y la sintaxis. Eso debería ser suficiente para empezar. ¡Vamos!

Ejecución de pruebas

Ya está listo para ejecutar las pruebas. RSpec requiere que los archivos de prueba tengan un sufijo específico como _spec para entender qué archivos ejecutar. Si utiliza un generador, esto no es una preocupación, pero si desea escribir los archivos de prueba por su cuenta, esto es lo que necesitan para terminar. Por lo que tendrá que poner un archivo como your_first_test_spec.rb en su directorio spec.

Usar el generador para crear un modelo ficticio ya nos proporcionó spec/models/dummy_model_spec.rb. ¡No está nada mal! Una cosa que queda por hacer antes de que las pruebas estén listas:

Terminal

1	rake db:migrate
2	rake db:test:prepare

Estos comandos ejecutan la migración para el modelo ficticio que generamos anteriormente y configuran la base de datos de prueba con ese modelo también. Ahora ejecutamos la prueba:

Terminal

rake

El comando rake ejecutará todas sus pruebas, la suite de pruebas completa. Por lo general, debe utilizar este comando cuando haya terminado alguna característica y desee ejercitar toda la suite de pruebas.

Salida

*
Pending: (Failures listed here are expected and do not affect your suite's status)

1) DummyModel add some examples to (or delete) /Users/vis_kid/projects/rspec-test-app/rspec-dummy/spec/models/dummy_model_spec.rb
   # Not yet implemented
   # ./spec/models/dummy_model_spec.rb:4

Finished in 0.00083 seconds (files took 1.94 seconds to load)

1 example, 0 failures, 1 pending

¡Felicitaciones! Acaba de hacer su primera prueba RSpec. No tan malo, ¿verdad? Por supuesto, esta era una prueba simulada por ahora—con código de prueba ficticio generado por Rails. La versión más enfocada de ejecutar sus pruebas, que tiene muchas más opciones que sólo eso—es ejecutar un archivo individual, por ejemplo. Como este:

Terminal

1	bundle exec rspec spec/models/dummy_model_spec.rb

Esto sólo ejecutará un único archivo de prueba en lugar del conjunto de pruebas completo. Con aplicaciones más grandes que dependen de una gran cantidad de archivos de prueba, esto se convertirá en un ahorro real en tiempo. Pero en términos de ahorro de tiempo y especificidad de prueba, esto es sólo arañar la superficie, para ser franco. Creo que vamos a cubrir más de cómo afeitarse una cantidad significativa de tiempo mientras se prueba en el tercer artículo de esta serie. ¡Vamos a ver hasta dónde llegamos!

La otra forma de ejercitar toda la suite de pruebas es simplemente ejecutar rspec—con o sin bundle exec, dependiendo de su configuración.

Terminal

1	bundle exec rspec

Una cosa más que debo mencionar antes de seguir adelante, también puede ejecutar sólo un subconjunto específico de pruebas. Digamos que sólo desea ejecutar todas sus pruebas para su código de modelo:

Terminal

1	bundle exec rspec spec/models

¡Fácil como eso!

Sintaxis básica

Recomiendo que comencemos con los fundamentos básicos y mirar en algunas opciones más que RSpec proporciona en los próximos dos artículos. Vamos a echar un vistazo a la estructura básica de una prueba y sumergirse en aguas más avanzadas cuando tenemos este uno fuera del camino.

describe

Este será su pan y mantequilla porque organiza sus specs. Puede hacer referencia a cadenas o clases:

Algunas especificaciones

describe User do

end

describe 'Some string' do

end

Las secciones describe son los elementos básicos para organizar sus pruebas en grupos lógicos, coherentes para probar. Básicamente, un ámbito para diferentes partes de la aplicación que desea probar.

Algunas especificaciones

describe User do
  ...
end

describe Guest do
  ...
end

describe Attacker do
  ...
end

Un buen consejo es apretar aún más el scope. Puesto que algunas clases crecerán bastante significativamente, no es una buena idea tener todos los métodos que desea probar para una clase en un solo bloque describe. Puede crear varios de estos bloques, por supuesto, y enfocarlos en torno a métodos de instancia o clase. Para hacer su intención más clara, todo lo que necesita es proporcionar el nombre de la clase con una cadena extra que hace referencia al método que desea probar.

Algunas especificaciones

describe Agent, '#favorite_gadget' do
  ...
end

describe Agent, '#favorite_gun' do
  ...
end

describe Agent, '.gambler' do
  ...
end

De esa manera obtendrás lo mejor de ambos mundos. Encapsulas pruebas relacionadas en sus grupos representativos mientras mantiene las cosas enfocadas y en un tamaño decente. Para los usuarios muy nuevos a Ruby, 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 olvide la coma después del nombre de la clase, ¡no funcionará sin ella! En un minuto, cuando lleguemos a expect, te mostraré por qué este enfoque es muy conveniente.

it

Dentro del ámbito de grupos describe, utilizamos otro ámbito de bloques it. Éstos se hacen para los ejemplos reales bajo prueba. Si desea probar el método de instancia #favorite_gadget en la clase Agent, se vería así:

Algunas especificaciones

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
    ...
  end

end

La cadena que proporciona al bloque it funciona como la documentación principal de su prueba. Dentro de ella, especifica exactamente qué tipo de comportamiento desea o espera del método en cuestión. Mi recomendación es no irse por la borda y ser demasiado detallado, pero al mismo tiempo no ser demasiado críptico y confundir a otros con descripciones demasiado inteligentes.

Piense en lo que la implementación más pequeña y más simple de esta parte del rompecabezas puede y debe lograr. Cuanto mejor escriba esta parte, mejor será la documentación general de su aplicación. No se apresure esta parte porque es sólo una cadena que no puede hacer ningún daño—al menos no en la superficie.

expect()

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. Volvamos a nuestro ejemplo anterior y lo vemos en acción (limitada):

Algunas especificaciones

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
    expect(agent.favorite_gadget).to eq 'Walther PPK' 
  end

end

Expect() es la "nueva" sintaxis de aserción de RSpec. Anteriormente se utilizó should en su lugar. Diferente historia, pero quería mencionarla en caso de que te encuentres con ella. expect() espera que le proporciones un objeto y que ejerza cualquier método bajo prueba en él. Finalmente, escribe el resultado afirmado en el lado derecho.

Usted tiene la opción de ir la ruta positiva o negativa con .to eq o .not_to eq por ejemplo (eq es corto para igual por supuesto). Siempre se puede dar la vuelta a la lógica—lo que mejor se adapte a sus necesidades. Vamos a ejecutar esta prueba sin sentido y centrarse en la salida que tenemos como resultado de nuestra configuración de prueba:

Terminal

1	rspec spec/models/agent_spec.rb

Salida

1	Failures:
2
3	1) Agent#favorite_gadget returns one item, the favorite gadget of the agent
4	Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'

Se ve muy bonito, ¿no? **"Agent#favorite_gadget devuelve un elemento y el gadget favorito del agent"** le indica todo lo que necesita saber:

La clase involucrada
El método bajo prueba
El resultado esperado

Si hubiéramos dejado la cadena que describe el método en el bloque describe, entonces la salida habría sido mucho menos clara y legible:

Algunas especificaciones

describe Agent do

  it 'returns one item, the favorite gadget of the agent ' do
    expect(agent.favorite_gadget).to eq 'Walther PPK' 
  end

end

Salida

1	Failures:
2
3	1) Agent returns one item, the favorite gadget of the agent
4	Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'

Claro, hay otras maneras de eludir y tratar con esto—pasando esta información a través del bloque it, por ejemplo—pero el otro enfoque es simple y funciona. Lo que hace que su flujo de sangre, ¡por supuesto!

Cuatro fases de una prueba

Las mejores prácticas en pruebas recomiendan que compongamos nuestras pruebas en cuatro fases distintas:

configuración de la prueba
Ejecucion de la prueba
Verificación de la prueba
Desmontaje de la prueba

Estas cuatro fases son sobre todo para la legibilidad y para dar a sus pruebas una estructura convencional. Es un llamado patrón de prueba, básicamente, una práctica que la comunidad acordó ampliamente que es útil y es recomendada. Todo este tema de patrones es un profundo agujero de conejo, así que sé que voy a dejar de lado un montón para no confundir a los principiantes entre ustedes a la muerte.

Instalación

Durante la instalación, se 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ña sugerencia: no complicar las cosas, y establecer sólo la cantidad mínima necesaria para hacer que el trabajo de prueba.

1	agent = Agent.create(name: 'James Bond')
2	mission = Mission.create(name: 'Moonraker', status: 'Briefed')

Ejecucion

Esta parte realmente se ejecuta la cosa que desea probar en esta spec. Podría ser tan simple como:

1	status = mission.agent_status

Verificacion

Ahora verifica si su afirmación sobre la prueba se cumple o no. Así que probar el sistema en contra de tus propias expectativas.

1	expect(status).not_to eq 'MIA')

Desmontaje

El marco se encarga de la memoria y los problemas de limpieza de base de datos—un restablecimiento, básicamente. No hay nada para que puedas manejar en este momento. El objetivo es recuperar un estado prístino para ejecutar nuevas pruebas sin sorpresas de las que se están ejecutando actualmente. Veamos qué significaría esto en un ejemplo falso:

Algunas especificaciones

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
  # Setup
    agent = Agent.create(name: 'James Bond')
    q = Quartermaster.create(name: 'Q') 
    q.technical_briefing(agent)

  # Exercise    
    favorite_gadget = agent.favorite_gadget
  
  # Verify
    expect(favorite_gadget).to eq 'Walther PPK' 

  # Teardown is for now mostly handled by RSpec itself
  end

end

Como se puede ver, en este ejemplo separamos el ejercicio y verificamos las fases claramente entre sí, mientras que en los otros ejemplos ficticios arriba, 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.

Lo difícil de las Pruebas

Ahora viene la parte difícil, que 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 comprensiblemente! Usted es nuevo en el lenguaje y el marco ya menudo ni siquiera sabe lo que no sabe. ¿Cómo se escriben las pruebas para eso? Muy buena pregunta.

Seré muy franco—no lo más probable—y no lo harás por un buen rato. Estar cómodo con estas cosas lleva un tiempo. Cuando usted tiene un mentor o asiste a algún campamento de entrenamiento y tal, 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 por ahí—te estás enseñando a ti mismo estas cosas, la paciencia será la clave. La lectura de todos los libros y artículos sin duda te lleva en la dirección correcta, pero creo que la prueba necesita un montón de piezas más avanzadas del rompecabezas en el lugar para que usted haga sentido completo y, tal vez aún más importante, antes de sentirse cómodo con él .

La "buena" noticia es que esto no es inusual y todos hemos estado allí. La perseverancia es importante. Usted puede hacer esto, no es ciencia de cohetes, pero tomará un rato hasta que usted pueda escribir una aplicación eficazmente de la otra manera alrededor—de la perspectiva de pruebas, quiero decir. Por ahora, seguir empujando, divertirse, cometer errores, escribir aplicaciones, copiar tutoriales y lo que sea, hasta que se apague la bombilla.

Consideraciones finales

Cuando escribes tus pruebas individuales, quieres hacer que sus objetos hagan lo más simple posible para lograr tu objetivo—las pruebas altamente enfocadas son realmente clave. Desea diseñar su aplicación a través de pasos muy sencillos y luego siga los errores que su suite de pruebas le proporciona.

Sólo implementar lo que es necesario para obtener la aplicación verde. ¡No más, no menos! Esa es la parte "guiada" en el desarrollo guiado por pruebas. Su trabajo se guía por las necesidades de sus pruebas.