Entonces, la pregunta es, ¿puedo hacer algo si el elemento está presente o no, ¿verdad? ¿Puedo hacer algo como si obtengo, digamos, un botón, ¿verdad, si no, entonces para eso lo llamamos testing condicional. Entonces, si vas a la documentación y dices condicional y tenemos toda la discusión sobre por qué no deberías hacer eso. Nunca quieres no saber qué esperar en la página. Si tienes que hacerlo, te damos soluciones alternativas, ¿verdad? Pero siempre quieres ir desde data, ¿verdad? Y siempre saber qué esperas en la página, ¿de acuerdo?
Puedes ver una discusión sobre esto antes de hacer un descanso. Entonces, estos son pruebas unitarias, ¿verdad? Si alguna vez usas solo un MockA, también solo que te gusta obtener tu función o código bajo prueba, realizas una sola acción y luego tienes una sola aserción. Y esto es importante porque si una prueba falla solo tienes el nombre de la prueba. Entonces, si tienes múltiples aserciones y una de ellas falla bueno, generalmente es difícil entender qué parte falló y por qué porque no hay un depurador de viaje en el tiempo. Para pruebas de extremo a extremo como estoy mostrando puedes escribir pruebas más largas. Jennifer, intenta buscar en nuestra documentación este enlace. De acuerdo, probablemente tengamos que. Así que observa, esta es una prueba típica. Va por donde usas la historia, paso a paso y tiene múltiples aserciones porque cada comando generalmente tiene una aserción incorporada. Si algo falla tienes video, tienes captura de pantalla puedes detener la prueba y ejecutarla tú mismo y ver qué hace. Entonces es mucho más fácil depurar una prueba larga y la prueba registrada realmente corresponde a toda la historia. Otra cosa para pruebas más largas es hacer lo siguiente que es bastante genial y mi cosa favorita para hacer después de haberlo aprendido. Mira esto. Voy a eliminar esos elementos. Voy a quitar esto. Solo voy a hacer la pausa del sitio y puedes hacerlo en cualquier lugar. Entonces, ahora mismo solo hizo la visita del sitio, ¿verdad? Y ahora puedo avanzar paso a paso a través de cada comando y puedo ver qué hace. Puedo abrir DevTools, ¿verdad? Puedo investigar qué hace mi aplicación en comparación con. Entonces, la pausa del sitio es realmente buena porque te permitirá escribir tareas más largas, comprenderlas, ¿verdad? Y luego usar el depurador de viaje en el tiempo para comprender tal vez lo que ha sucedido también. Entonces, mi regla personal es si estás describiendo un pequeño fragmento de código solo escribe una prueba unitaria, más larga como una historia de usuario es de extremo a extremo. Puedes dividir, no, especificaciones. Puedes organizarlos por carpetas. Cypress puede ejecutar en las subcarpetas. Y luego estábamos escribiendo pruebas individuales, ¿verdad? Pero también puedes agruparlas, ¿verdad? Puedes decir, esto, digamos, describir, digamos, alternar. Y luego puedes tener una serie de pruebas dentro, describiendo una funcionalidad. Y puedes tener ganchos comunes antes de cada uno, para configurar los datos para esa cosa en particular.
Entonces, Lindsay, si entiendo correctamente, la pausa del sitio es un comando que puedes agregar a tu prueba para pausar en un lugar específico y luego avanzar paso a paso en la prueba, ¿de acuerdo? Así que he mostrado cómo escribir una prueba que recorre la interfaz de usuario de tu aplicación y ejecuta las mismas acciones que el usuario para agregar un elemento, eliminar un elemento, alternar, ¿verdad? Y luego asegúrate de que cuando agregues esos comandos, no solo agregues comandos, comandos, como verificar, obtener, escribir, hacer clic. También quieres asegurarte de agregar aserciones. Si agregas un elemento, debería haber más elementos, ¿verdad? Como, esperamos un número de elementos. Si completas un elemento, debería agregarse o eliminarse una clase. No solo realices acciones, combina acciones y aserciones.
Entonces, Eric, definitivamente recomiendo KitPitch, ¿verdad? Esto es lo que se necesita para escribir una presentación de diapositivas de KitPitch. Solo escribe markdown como se muestra aquí. Separas las diapositivas y luego incluyes imágenes en VectorRepo. Y si usas su URL, el mismo archivo se muestra como una presentación de diapositivas. Lo más simple. Ahora se están alejando, así que tendré que encontrar algo más. Entonces, para mis necesidades y para la empresa, realmente usamos Slides.com porque son increíbles, ¿verdad? Saben lo que están haciendo. Conocen la interfaz de usuario, la experiencia es simplemente increíble. Usan Cypress para probarlos, nosotros los usamos para mostrar. También pueden importar markdown. Así que probablemente cambiaremos a ellos porque git pitch se está alejando, pero fue bueno mientras duró. Así que creo que está bastante cerca. Probablemente podrás tomar el markdown y generar diapositivas en un par de pasos. Eso, pero no lo sé, aún no lo he hecho. ¿Las pruebas de extremo a extremo de Cypress reducen la importancia de las pruebas de integración y viceversa? Entonces, la prueba de integración es una prueba donde tomas, digamos, un par de componentes y tratas de ver cómo funcionan juntos, ¿verdad? Tal vez con algunas otras partes de las cosas. Entonces, sí y no, ¿verdad? Pero yo comenzaría con pruebas de extremo a extremo porque es la única prueba que importa para los usuarios. Y lo que veremos muy pronto es que podrás detener partes de tu aplicación, incluso desde Cypress, por ejemplo, como llamadas de red, etc. Así que diría que comiences con pruebas de extremo a extremo porque no reducen la importancia de la integración, pero creo que son más importantes que la integración cuando comienzas, especialmente. Y cuando puedas agregar pruebas de integración, como ves, cosas que son difíciles de probar para cosas de extremo a extremo. De acuerdo, continuemos.
Entonces, una sección muy corta, seleccionar un playground y Cypress Studio. Así que tengo esto como un capítulo muy corto, así que ni siquiera importa probarlo tú mismo. Pero aquí está la cosa. Entonces, estábamos discutiendo los selectores. Yo uso los elementos de DevTools, ¿verdad, para encontrar el selector? Por ejemplo, este input, incluso Chrome sugiere input con una clase new to do. De acuerdo. Pero, ¿dónde está abrir, podemos abrir el selector playground. Entonces, así es como funciona. Digamos que tengo esta prueba y necesito agregar, ¿verdad, un elemento. De acuerdo, ¿qué es esta caja? Entonces, voy a hacer clic en abrir selector playground. Y ahora, puedo simplemente pasar el cursor sobre los elementos y sugerirá. Por ejemplo, mira cómo si uso data side, el ID de prueba, hablará de vuelta. Si no, elegirá, ya sabes, una clase. Entonces, aquí, una vez que elijo eso, incluso me dice el comando, puedo copiarlo y veamos, pégalo aquí. Y puedo decir escribir, texto más enter. Así es como seleccionaría, ya sabes, un elemento. El problema con ese selector, ¿verdad? Entonces, si, por ejemplo, intento seleccionar este elemento, no creo que tenga mucho sentido. Como este selector. Entonces, todavía es imperfecto, diría yo. Pero aquí hay algo más que muchas personas nos preguntan, como desde hace mucho, mucho tiempo. Digamos que no tengo nada aquí. ¿De acuerdo? ¿Puedes simplemente hacer clic en la aplicación y ver si puedes grabar la prueba a partir de las acciones del usuario? ¿De acuerdo? Entonces, en Cypress 6.3.0, básicamente, la semana pasada, lanzamos una función experimental. Entonces, para que puedas ver esto, debes ir a un archivo Cypress JSON y decir experimental studio true. Así es como controlamos los experimentos, ¿verdad? No los cargamos de forma predeterminada. Pero si lo habilitas en tu proyecto, una vez que la prueba haya terminado, verás esto justo cuando pases el cursor sobre el nombre de la prueba. Entonces, agregar comando a una prueba. Así que haces clic en eso. Ahora esto se llama modo Studio, ¿verdad? Entonces, interactúa con tu sitio para agregar comandos de prueba. Entonces, quiero decir primero to do, enter, segundo to do, enter. Entonces, observa que realmente interpreta correctamente los comandos y no permite todo, solo se observan algunos comandos. Pero cuando hago clic en guardar. Espera.
Comments