[ ] requires
[ ] Te permiten saber si tu cambio está perdiendo una funcionalidad [ ] Te permiten detectar bugs que se reabren [ ] No vas a ciegas. Puedes saber como está la aplicación.
[ ] Tu código es la teoría [ ] Los tests son los experimentos [ ] La realidad… es la realidad [ ] Como en ciencia, la idea es que se rompa
[ ] No toda funcionalidad merece ser testeada [ ] Testea el dinero [ ] Testea los puntos clave [ ] Decide qué merece la pena probar [ ] Involucra al cliente y sus prioridades
[ ] Tengo 2.000 tests ¿y hacen falta? [ ] Unos tests que tardan 10 minutos, ¿son buenos? [ ] Poda de tests ¿Merece la pena testear relaciones entre modelos?
[ ] Durante el desarrollo testea ese desarrollo [ ] Durante la integración, testealo todo
[ ] Se testean las piezas pequeñas [ ] Son tests normalmente rápidos [ ] El scope es pequeño, son más sencillos (no siempre) [ ] Las piezas pueden funcionar, pero el puzzle no. [ ] Al cliente le importa el puzzle
[ ] Se testea la aplicación al completo [ ] Son tests tan lentos como tu aplicación (y algo más) [ ] Su scope es amplio y puede llevar más tiempo encontrar los errores [ ] Si el puzzle funciona, todo está bien [ ] Javascript, Capybara, Poltergeist
[ ] Métrica engañosa [ ] Una línea cubierta no es una línea segura [ ] Una línea no cubierta sí que no es segura [ ] El porcentaje no debe bajar
[ ] Un test por método [ ] Un fichero por clase [ ] Un requisito por test
[ ] Aplicaciones mantenibles [ ] Patrones de diseño [ ] Las suite de tests son un punto negro [ ] Lo primero en dejar de ser mantenido [ ] Lo hecho más aprisa
[ ] Los tests no son un extra [ ] Los tests no son una obligación [ ] Los tests también son código [ ] Si no tiene JS no está terminado [ ] Si no está testeado tampoco
[ ] No sobretesteis [ ] Pero cuando haga falta, defendedlo a muerte [ ] Una carpeta por clase/funcionalidad [ ] Un fichero por contexto general de test [ ] Los requisitos necesarios por tests, no más, no menos.
[ ] Enfoque distinto a otros testing (JUnit) [ ] Se abstrae de métodos, clases, etc. [ ] Maneja contextos y escenarios de código (no de la aplicación entera)
[ ] Tiene una descripción [ ] Describen un contexto, normalmente en la forma “when X is happening”, “when the user does Y”, “when we Z” [ ] Son anidables [ ] No llevan código a testear [ ] Normalmente, un describe con context anidados
[ ] Tienen otra descripción [ ] Describen lo que se espera que suceda, normalmente algo como “should notify X”, “should show Y to the user”, “should create Z” [ ] No son anidables [ ] Llevan el código a testear [ ] Puede haber varios en un mismo context [ ] Es el punto de ejecución
[ ] Dos its son dos ejecuciones [ ] Puede tener sentido ejecutar un test tras otro, no en paralelo [ ] En un funnel, testear paso a paso la ejecución normal [ ] Fallos más granulares [ ] Te echo de menos cucumber [ ] Escenarios muy particulares en un único paso
[ ] Pueden tener un mensaje asociado al error [ ] Especifican una condición a nivel de código y datos que debe cumplirse [ ] expect(…).to condition [ ] expect(UserNotification.last.message).to eq message [ ] expect(page).to have_content message [ ] expect(Z.count) to eq 1
[ ] let: Memoiza ejecución de código [ ] Se usa para definir objetos que tendrán relevancia en el test [ ] Se ejecuta la primera vez que se le llama [ ] let!: Fuerza la ejecución antes de empezar el test [ ] Permite cargar datos en la BD sin tener que llamar a muchos lets [ ] subject: Define el sujeto del test [ ] Antes permitía definir escenarios y requisitos más fácilmente [ ] Te permite dejar claro el foco del test
[ ] before/after: Código que se ejecuta antes/después del escenario [ ] :each/:all: Una vez por escenario / Una vez en global [ ] con let! se minimiza su uso
[ ] Meta información para contextos y escenarios [ ] Se puede leer en before/afters [ ] Caso UE: Tests responsive
[ ] Ejemplo de test [ ] Ejemplo de ejecución
[ ] Define campos “normales” [ ] Define relaciones [ ] Define campos únicos, con iteradores [ ] Te permite aislar la definición de datos, desde el test solo pides “un hotel con habitaciones y fotos”
[ ] Distintos escenarios necesitan distintos datos [ ] Crear ‘n’ factorias para los distintos casos (hotel, hotel con habitaciones, hotel con fotos, hotel con habitaciones y fotos) [ ] Las factorías pueden heredar [ ] Crear una factoria y “traits” (hotel, con habitaciones, con fotos)
[ ] build: crea el objeto, no lo guarda [ ] create: Crea el objeto y lo guarda [ ] attributes_for: Hash de atributos
[ ] No sigue los pasos normales de ActiveRecord [ ] En ciertos casos puede no interesar
[ ] allow(class_or_instance).to receive(a_method).with(some_parameters).and_return(something) [ ] Puedes mockear la clase, una instancia en particular o todas las instancias [ ] mockeas método a método [ ] Los parámetros son opcionales. Permite devolver cosas distintas según el parámetro de entrada [ ] Te permite devolver lo que quieras
allow(Product).to receive(:get_by_filters).with({:product_code=>product_code},true).and_return([product_2,product_3])
[ ] expect(class_or_instance).to receive(a_method).with(some_parameters).and_return(something) [ ] Igual que el allow pero exige que se llame el método [ ] Permite especificar número de llamadas [ ] Útil para probar, por ejemplo, caché de fragmentos
[ ] No tienes que preocuparte de la otra parte [ ] Se necesita una interfaz definida entre las cajas [ ] Tests más rápidos [ ] Cambios en un lado no rompen el otro
[ ] Cambios en un lado no rompen el otro [ ] ¿Deberían? Falsos positivos [ ] Definición de interfaz entre cjas en muchos sitios
[ ] Delorean o Timecop: Mock de Time.now para viajar en el tiempo
[ ] Librería de mocks especializada en peticiones de red [ ] “Mockea” Net::HTTP [ ] Graba peticiones HTTP en JSON o YAML y luego las reproduce
[ ] Exige una primera iteración sin mock [ ] Los ficheros vcr se generan y se meten al repo [ ] Los ficheros VCR se pueden crear o tocar a mano
[ ] Criterio de path [ ] Criterio de parámetros [ ] Criterio custom
[ ] Passwords en peticiones [ ] Hace un find and replace de cadenas
[ ] Se puede especificar dentro del it: VCR.use_cassette cassete_name { … } [ ] En los metadatos del contexto o el escenario
[ ] Caso especial de problema de dependencias de mock [ ] Su parte puede cambiar sin previo aviso [ ] Desactivar mock [ ] Tenemos la prueba de que antes funcionaba
[ ] Permite definir un conjunto de contextos y escenarios reutilizables [ ] Puede recibir parámetros [ ] Lee datos de lets externos
[ ] Ramas a testear [ ] Hooks para ejecutar procesos [ ] Caso clásico: secrets [ ] Personalización de tests a ejecutar ¿Suite de desarrollo? ¿Suite de integración?
[ ] Alta de repositorios [ ] Ejecuciones
[ ] Testing en PR [ ] Ramas a testear