En esta publicación, quiero compartir una revisión de 15 informes de la conferencia de Heisenbug, para decirte lo que fue interesante en los stands de las empresas, y también para compartir material de video del informe de Artyom Eroshenko sobre la creación de complementos de acción para IntelliJ IDEA que te ayudará a cambiar rápidamente el código del proyecto de prueba.
Información sobre HeisenBug
Heisenbug - Conferencia técnica para especialistas en pruebas. Es de interés principalmente para los probadores, ingenieros de desarrollo de software en pruebas y especialistas en pruebas automatizadas y de carga. Los organizadores son el equipo
JUG.RU , detrás del cual se encuentran conferencias como Joker, HolyJS, SmartData, DevOops, DotNext, Mobius.
Lugar
La quinta conferencia se celebró en el hotel Slavyanskaya Radisson, estación de metro Kievskaya, Moscú. Al acercarse al hotel, se veía una pancarta electrónica con el logotipo de la conferencia. Además, en la entrada del vestíbulo del hotel, el participante estaba acompañado de carteles en los mostradores de facturación y el armario. Es imposible perderse. El registro de participantes y oradores se realizó en la planta baja, en el vestíbulo principal de la conferencia había puestos de socios, salas de conferencias, salas con un café y almuerzos. El nivel de los guardias de seguridad complació, por lo que los "conejos polizones" no debían llegar. En total, al evento asistieron más de 500 participantes, la mayoría de los cuales se registraron dos semanas antes del comienzo.
El programa
El programa se puede encontrar
aquí . Quiero señalar que
JUG.RU siempre se esfuerza por hacer que el programa sea práctico, sin agua adicional y con expertos extranjeros conocidos. Los informes se dividen en símbolos:
Si esta es la primera vez que planea convertirse en un orador en Heisenbag, mire la
nota del orador : contiene bastante información útil.
Comunicación y voluntariado.
Para que los participantes no se perdieran algo importante en la conferencia, se organizó un canal de telegramas y un chat de telegramas. Por cierto, en este último buscaban voluntarios para ver videos, para lo cual dieron un boleto de conferencia gratis.
Si decide ser voluntario, indique su decisión a los organizadores lo antes posible. La preparación para el evento se lleva a cabo mucho antes de la conferencia. Sujeto a disponibilidad, será asignado al equipo.
Stands de la empresa
Esta vez, la conferencia contó con más de una docena de stands de grandes empresas de TI, como Deutsche Bank, Alfa-Bank, Raiffeisen, Badoo, Luxoft, SKB Kontur, Gett, etc. Cada una de las empresas abordó la organización de las interacciones con los participantes del evento a su manera. , así que entre las actuaciones no tenía que aburrirse. Fue posible resolver problemas para un pequeño recuerdo memorable, jugar video y juegos de mesa, y participar en la lotería.
Raiffeisen ofreció realizar una búsqueda en línea con una solución para todo tipo de acertijos, también los conocedores de clásicos eternos podrían jugar Mortal Kombat 3 en Sega. Los colegas de Alfa-Bank hicieron un bot de telegramas con tareas, además de un gran conjunto de Lego Mindstorms en la lotería. Quiero elogiar el stand de Deutsche Bank, donde los desarrolladores de comunicación en vivo dieron tareas y participaron en la discusión, a diferencia de todos los demás stands, donde solo verificaron las respuestas.
Muchas compañías cazan discretamente a especialistas, entregando folletos que describen las vacantes (no es lo mismo participar en obras de caridad).
Resumen de informes
1. Tenemos DevOps. Vamos a despedir a todos los probadores : Baruch Sadogursky.
La conferencia fue inaugurada por Baruch Sadogursky, defensor de desarrolladores de JFrog, un conocido orador en conferencias relacionadas con Java y Devops. En el informe, Baruch abordó los problemas de calidad del software frente a los lanzamientos frecuentes, que son causados por las demandas comerciales en constante crecimiento, la complejidad de las pruebas de código debido a la mala arquitectura y la modernización del papel del probador en los equipos ágiles modernos. Fue interesante escuchar el informe de principio a fin, mucho humor, hechos interesantes y comparaciones.
Bueno, las ideas principales del informe se pueden poner en una diapositiva, que ilustra que la automatización de pruebas y las prácticas de DevOps reducen los costos de tiempo de los procesos de rutina y le permiten dedicar más tiempo a la implementación de nuevas tareas.
2. ¿Necesita refactorizar un proyecto? Hay IDEA! - Artem Eroshenko.
Artyom en su informe habló sobre la creación de complementos de
acciones para IntelliJ IDEA, que lo ayudarán a cambiar rápidamente el código del proyecto de prueba.
Dio una explicación de las clases principales (AnAction, PsiClass, PsiAnnotation, AnActionEvent, JavaCodeStyleManager), que son el punto de entrada de las acciones del complemento.
Consideró cómo resolver las siguientes tareas:
a) Qué está automatizado en el proyecto y qué no. Sincronización automática con Jira.
Según el texto de la anotación, @DisplayName fue a Jira, recibió los tickets necesarios y dejó todas las conexiones necesarias utilizando @TmsLink.
b) Pegar automáticamente @Tags desde el contexto de Jira.
Hay ciertas etiquetas en el
boleto de regresión favorito . Vamos a la prueba, hay anotaciones @TmsLink, usamos el complemento y tenemos nuevas anotaciones @Tags, y luego, con la ayuda de Junit, podemos ejecutar pruebas en estas etiquetas.
c) ¿Qué se verifica en las pruebas?
Hay una prueba automática, hay pasos, exportamos y tenemos pasos en las pruebas. También en el video hay un ejemplo para dos pruebas.
Artyom también demostró cómo cambiar rápidamente de Allure 1 a Allure 2.
Un informe muy práctico para aquellos que están pensando en optimizar el proceso de escribir código. El código fuente de los complementos se puede encontrar
aquí .
3. ¿Proyecto Java y Reactor? - Pero, ¿qué hay de las pruebas? - Kirill Merkushev.
Cyril compartió su experiencia en el desarrollo de la startup médica internacional Vivy. Contó cómo se resolvieron los problemas de escalabilidad de un sistema monolítico utilizando microservicios y la biblioteca Reactor. Se prestó mucha atención a esta biblioteca, sus principios básicos, enfoques para probar sistemas reactivos, características asesinas (como puntos de control y registros en la cadena de solicitudes, ganchos y solicitudes repetidas (reintento).
Personalmente, no me ocupé de probar sistemas reactivos, así que para mí fue nuevo e interesante.
4. Mientras escribíamos el marco Sealant para buscar pérdidas de memoria en JS , Sergey Dokuchaev.
Esta charla trata sobre pérdidas de memoria (objetos accesibles desde el código pero que ya no son necesarios) en aplicaciones web de una sola página. Sergey estableció la tarea de encontrar automáticamente todas las pérdidas de memoria críticas en la versión lanzada del producto. Habló sobre las dificultades de encontrar tales errores y cómo hacerlo manualmente usando las herramientas de Google Chrome. Luego, examiné la herramienta
SeaLant , de la cual él es el autor. SeaLant automatiza la detección de fugas al interactuar con el proceso de Chrome utilizando el protocolo Chrome DevTools. El informe terminó con el hecho de que si la página puede ejecutar secuencias de comandos cíclicas (desde un dispositivo, con una sesión, sin volver a cargar la página), lo más probable es que, al probarlas, pueda deshacerse de la mayoría de las pérdidas de memoria.
5. Características de las pruebas visuales de las interfaces : Anton Usmansky, un desarrollador líder de herramientas Gemini (una herramienta de prueba visual) y Hermione (una herramienta de propósito general más de próxima generación que puede realizar afirmaciones de captura de pantalla).
El informe es útil para aquellos que están pensando en implementar herramientas de prueba visual en sus proyectos. Aquellos que ya usan Gemini y Hermione también pueden estar interesados, ya que da una idea de cómo se organizan las herramientas en su interior. En algunos lugares, el autor se ocupa de cosas bastante básicas.
6. Problemas en Selenium WebDriver - Alexey Barantsev.
Alexey habló sobre los problemas del proyecto Selenium y las razones de su ocurrencia. Compartió los detalles del ensamblaje del mono-repositorio utilizando el colector
Bazel . Tocó el tema de la visibilidad del elemento (en el estándar W3C WebDriver no hay ninguna operación que verifique si un elemento es visible o no) y explicó cómo difieren las funciones getProperty, getDomAttriubute, getAttribute.
Conocer los problemas permitirá a los usuarios distinguir las características de los errores y desarrollar "muletas" efectivas en sus proyectos de prueba.
7. Recetas para crear desde cero y el desarrollo de un sistema de prueba de carga - Anatoly Plaskovsky.
Anatoly representa el grupo de investigación de rendimiento Yandex.Money. En su informe, compartió sus prácticas sobre cómo determinar la necesidad de realizar estudios de desempeño, dónde encontrar personas para realizar estas actividades y cómo construir un proceso de investigación. El autor se centra en el hecho de que la investigación de rendimiento = Pruebas de carga, y que solo las pruebas en producción pueden mostrar un resultado relevante. Al mismo tiempo, es posible realizar experimentos sin problemas para los clientes eligiendo rutas de prueba y datos, monitoreando y prediciendo los posibles resultados del escenario.
Anatoly creó un campo de carga de chat de telegramas, que analiza las pruebas de carga y dónde puede llamar para obtener ayuda y consejos.
8. Fallos épicos de los fabricantes de dispositivos - Valentine Wylsacom Petukhov.
El primer día fue cerrado por el informe del notorio Wylsacom, que fue percibido de manera ambigua por el público (a juzgar por el chat de los participantes en el heisenbag en un telegrama :)).
Para mí, no tomé nada interesante del informe sobre las pruebas beta de dispositivos y aplicaciones, pero tal vez a los fanáticos les gustó. El área de discusión se alineó para la foto, por lo que las relaciones públicas fueron un éxito.
9. Pruebas de integración elegantes del zoológico de microservicios usando TestContainers y JUnit 5 usando el ejemplo de la plataforma global de SMS - Andrey Markelov.
El autor contó cómo se prueban los microservicios en su empresa utilizando el paquete Testontainers + Junit 5 + MockServer. El informe sonaba interesante, pero este esquema no es para una gran cantidad de microservicios. Enlace al
código fuente.
10. Voyeurismo del probador, o Cómo le ayudará el monitoreo de los usuarios - Antonina Khisametdinova.
Un informe muy interesante, aunque más relacionado con el diseño web que con las pruebas. Habla sobre las prácticas de UX y las dificultades que deben evitarse al diseñar la interfaz del cliente.
Antonina identificó los principales errores al observar a los usuarios en soluciones de IU como deshabilitar botones, usar cargadores, información sobre herramientas, componentes familiares, etc.
También vale la pena señalar el diseño gráfico del informe con ejemplos intuitivos de proyectos reales (como corresponde a los informes sobre UX).
11. Pruebas de sistemas con dependencias externas: problemas, soluciones, Mountebank - Andrey Glazkov.
El autor habló sobre la evolución de las etapas de humectación en sus proyectos. Consideró los pros y los contras de burlarse a nivel de código. Compartió su experiencia, en cuyo caso es bueno crear una implementación de servicio falsa. Pero si desea que los servicios falsos se reconstruyan sobre la marcha, por proxy y, al mismo tiempo, se ingresen los registros de las solicitudes entrantes, Andrey recomienda echar un vistazo más de cerca a la herramienta
Mountebank .
Las principales ventajas:
- mounteBank: funciona a nivel TCP;
- Inyección de JavaScript;
- fiabilidad y rapidez fuera de la caja;
- excelente documentación;
- soporte de contenedorización de docker.
Limitaciones identificadas de la herramienta:
- sistemas externos con almacenamiento de datos;
- WebSocket: no compatible;
- pruebas de carga (> 150 rps), pero puede usar un equilibrador.
12. Por qué realizar pruebas de perfil de aplicaciones móviles - Vyacheslav Frolov.
En su informe, Vyacheslav habló sobre el estado de las pruebas automáticas en Badoo, a saber, cómo resolvieron el problema de paralelizar 1.500 pruebas de IU móviles, que tardan 30 horas en ejecutarse en un simulador. Como resultado, lograron un resultado de 30 minutos, lo que les permitió ejecutar 80 mil pruebas por día. Además de un aumento lineal en la potencia, se aplicó la optimización para borrar el caché de la aplicación en lugar de reiniciar el simulador. Los perfiles también se mencionaron en el informe y cómo se usaron para detectar casos especiales de cuellos de botella en las pruebas: por ejemplo, el método long_press () en ios 11.0 se ejecutó durante 5 segundos, y después de la optimización comenzó a ejecutarse en un segundo, o cómo con la ayuda del encabezado http -alive "puede evitar restablecer la conexión, acelerando significativamente todas las pruebas a la vez. El autor también contó cómo mostrar los resultados del generador de perfiles utilizando las herramientas FlameGraph y FlameChart.
13. Pruebas unitarias: de la teoría a la práctica - Vadim Pushtaev.
El autor comparte su experiencia en el desarrollo de UnitTests. El informe constaba de tres partes.
- ¿Qué queremos de UT → Regresión (Cambió el código, comprobó), Influencia en la arquitectura (Cuando los desarrolladores escriben pruebas, el código mejora), Comprensión (para lidiar con el código heredado);
- Principios → Vadim recuerda que la teoría no es tan buena como la práctica. Rechazó el principio de "probar la interfaz, no la implementación", ya que puede haber mucha lógica en la implementación. Además, el principio "pruebas unitarias no es un mecanismo de prueba". Considera que este es un tipo de técnica arquitectónica, potente y muy útil, pero no es un mecanismo para verificar y corregir el código.
- Implementación → Una historia sobre las técnicas que utiliza el autor en el trabajo (para cada clase hay una clase de prueba, la creación de sus propios comparadores, el uso de dependencias externas, si es necesario, etc.).
14. Prueba y llanto con la prueba de arranque de primavera - Kirill Tolkachev
Cyril decidió devolvernos al mundo de IoC, DI y Spring y decirnos cómo escribir pruebas unitarias y de componentes usando JUnit 5 y SpringBoot.
Una gran ventaja de este informe es que el orador escribió la mayoría de las pruebas en tiempo real, es decir. demostró claramente el proceso paso a paso de ajustar las pruebas con anotaciones Spring. Sin embargo, debido a la gran cantidad de código, fue difícil poner todas las técnicas mostradas en mi cabeza. Cyril revisó las características de Spring para trabajar con perfiles, Mock & Spy Beans, así como establecer configuraciones de contexto. En cuanto a mí, Spring es un marco bastante pesado para tales tareas y solo los usuarios experimentados podrán no pisar el rastrillo cuando desarrollen pruebas unitarias.
15. Bombeamos
autotests móviles - Ekaterina Bateeva.
En el informe, el autor examinó la herramienta XCTest para automatizar aplicaciones iOS. Duplicar esta herramienta en otros proyectos fue inconveniente.
A saber, se identificaron las siguientes desventajas:
- configuración de inicio difícil de leer;
- ensamblajes difíciles de configurar;
- difícil de integrar con varios servicios;
- inconveniente para administrar capturas de pantalla;
- inconveniente para configurar reinicios de prueba.
Luego, Catherine habló sobre el marco
Fastlane de código abierto, que resolvió sus problemas.
Resumen
En general, me gustó la conferencia. Recibió un cargo de emociones y respuestas a preguntas de interés. En la sesión de BoF, la mayoría de los participantes se quitaron sus "máscaras" y tuvieron acaloradas discusiones en el marco de los temas de BoF. Las pausas para el café y las cenas eran perfectas, siempre había algo para comer. También quiero señalar la organización del evento: el equipo de JUG.RU cada vez hace que Heisenbug sea cada vez mejor. Finalmente, ¡vaya a conferencias, comparta los conocimientos adquiridos y mejore sus habilidades!
PD: Expreso mi gratitud a Alexei Rumyantsev por participar en la preparación del artículo y a Artem Eroshenko por el material de video.