Anotación

El artículo habla sobre la forma poco convencional pero útil de las pruebas, y también resume los resultados de siete años de trabajo en el desarrollo de pruebas.

¿Por qué necesita pruebas de componentes?

Después de todo, hay, por ejemplo, pruebas unitarias que prueban en detalle los despojos de los componentes. Verifican a fondo que el componente funciona de acuerdo con la intención del desarrollador. Pero a menudo esto es una comprobación de botones, y no cómo se sienta el traje en su conjunto. Y no siempre el comportamiento concebido por el programador coincide con lo que el cliente quería.

Y hay, por ejemplo, pruebas de aceptación. Y eliminan todas estas deficiencias. Pero, desafortunadamente, están introduciendo nuevos. Son lentos, a menudo inestables y generalmente mansos. Sin embargo, solo indican un problema, pero no lo localizan.

Obviamente, surge la necesidad de pruebas intermedias, que serán la media de oro entre las pruebas unitarias y de aceptación. Este término medio puede ser pruebas de componentes.

¿Qué son las pruebas de componentes?

Estas son pruebas para la API del componente público. En consecuencia, están escritos en el mismo idioma que el componente. Objetivo de prueba:

• verificar el cumplimiento de los componentes con sus contratos
• verificar cumplimiento
  Esto último es especialmente importante ya que las pruebas unitarias generalmente se escriben en función de las expectativas del desarrollador, pero aquí debe verificar las expectativas de los clientes.

Obviamente, las pruebas de componentes tienen sentido cuando tiene componentes dedicados con una interfaz extensa. Por ejemplo, una biblioteca dinámica o un objeto COM. Entonces las pruebas de componentes darán el máximo efecto.

Ventajas de las pruebas k:

• Dar estabilidad al desarrollo. Obviamente, una verificación exhaustiva de las interfaces públicas le permite mantener el componente en una forma más o menos eficiente.
• Localiza con precisión los problemas. Incluso si la prueba del componente en sí es bastante general, siempre se puede depurar en profundidad, llegando rápidamente al código de batalla. En este caso, el entorno de prueba será mínimo y se configurará automáticamente.
• Acelere el desarrollo con un número crítico de desarrolladores. Los programadores son conocidos por ser como caballos. Si un caballo tira de un carro con una capacidad de 1 litro. s., luego se tiran ocho caballos con una capacidad de solo unos 4 litros. s Y la adición de otro desarrollador al equipo (especialmente al final del proyecto) a menudo no solo no acelera, sino que también lo ralentiza. Si bien la adición de un desarrollador de pruebas de componentes siempre es una ventaja, ya que actúa de manera relativamente independiente del equipo: realiza pruebas (esencialmente externas), acelera la compilación de la compilación, optimiza los archivos de ensamblaje, etc.
• Aclarar (y luego verificar) los requisitos del cliente. Como el desarrollador de las pruebas de componentes no está vinculado a la implementación, se ve menos afectado por el efecto "Sé cómo hacerlo yo mismo". En el caso de un requisito ambiguo, el desarrollador ordinario se inclina a hacer lo que sea conveniente (más interesante, más rápido, más fácil). Mientras que el desarrollador ct en este caso se inclina a especificar qué es exactamente lo que espera el cliente.
• Relativamente estable y relativamente rápido (en comparación con las pruebas manuales y las pruebas automatizadas a través de la interfaz de usuario).

Contras de las pruebas K:

• Tiempo de desarrollo y apoyo. Obviamente, la versión alfa del producto, si se pasa parte del tiempo escribiendo pruebas de componentes, aparecerá más tarde. ¿Habrá una ganancia en general? ¿Habrá un lanzamiento antes? Esta es una buena pregunta Mi opinión: cuando se desarrolle con pruebas de componentes, la versión se lanzará aproximadamente al mismo tiempo. Pero, con menos rumores y más predecible en términos de tiempo. El tiempo de desarrollo aumentará naturalmente, se reducirá el tiempo de corrección de errores y la estabilización. Dado que la segunda parte es mucho menos predecible, su reducción tendrá un efecto beneficioso en la cantidad de procesamiento y molestias. Sin embargo, esta es solo mi experiencia, y la realidad puede ser diferente. Es posible que el tiempo asignado para las pruebas de componentes se invierta ineptamente para duplicar las pruebas unitarias existentes.
• Menos intercambiabilidad. La separación de roles aumenta la eficiencia, pero reduce la intercambiabilidad. Los desarrolladores rara vez quieren profundizar en las pruebas de componentes, que pueden tener (o simular) un entorno bastante complejo. Los desarrolladores de pruebas de componentes están lejos de conocer el código de batalla tan bien que puede editarse fácilmente.
• Duplicación molesta. Con buenas pruebas unitarias, las pruebas de componentes a menudo resultan ser en su mayoría redundantes. Esto es molesto y cuestiona su necesidad. La coordinación de los planes unitarios y las pruebas de componentes ayudan, pero por lo general la duplicación no se elimina por completo.
• La necesidad de seguir el flujo de trabajo correcto. Una vez recibidos los requisitos, la tarea debe ponerse simultáneamente en el desarrollador y desarrollador de las pruebas. Luego terminan de trabajar aproximadamente al mismo tiempo. El componente se ejecuta a través de pruebas, los errores se detectan y corrigen rápidamente y se utiliza un producto más o menos terminado para salir. En este caso, los beneficios de las pruebas de componentes se maximizan. Pero a menudo sucede que los plazos son profanos desde hace mucho tiempo, todos se abandonan para escribir solo código y el componente se envía a pruebas manuales sin pruebas. Y solo entonces invitan al desarrollador de las pruebas: dicen que no es bueno que el código sin las pruebas haya sido lanzado, deberíamos agregarlos. En este caso, los probadores manuales encuentran la mayoría de los errores, los desarrolladores realizan correcciones a ciegas (o prueban los cambios a mano) y las pruebas posteriores a los hechos solo encuentran un pequeño número de errores (lo que afecta negativamente la moral de su escritor). Tal uso de pruebas de componentes es inútil en el mejor de los casos, y es difícil asegurarlo.
• Hay pocas personas adecuadas. El desarrollador de pruebas de componentes debería, por un lado, poder escribir código en el lenguaje del componente (y esto, por ejemplo, C ++). Además, si el entorno para iniciar el componente es extenso, el código puede ser bastante complicado. Y, por otro lado, ser capaz de probar meticulosamente el trabajo de otra persona. No hay muchas personas así, y generalmente van inmediatamente a los desarrolladores. Pero todavía hay esas personas, y la siguiente parte sobre ellas.

Resumen 1

Las pruebas de componentes son buenas, pero solo si tiene todas las condiciones para ellas: una API pública amplia, el flujo de trabajo correcto y las personas adecuadas en el equipo.

¿Cómo es ser un SDET?

Obviamente, SDET - Ingeniero de desarrollo de software en prueba es un candidato ideal para escribir pruebas de componentes. Él sabe cómo escribir código y sabe cómo pensar en las pruebas. También proporciona una segunda opinión, que también mejora la calidad de las pruebas y el código. Todo esto suena interesante y tentador, tal vez ya quieras ser uno. Aquí te contaré brevemente cómo el trabajo de SDET difiere del trabajo de un desarrollador puro.

Ventajas de trabajar con SDET:

• Nuevo código Casi siempre, SDET escribe pruebas desde cero. Y a menudo, un entorno se escribe desde cero. Es muy agradable y ofrece un gran margen para la creatividad.
• Baja dependencia del código heredado. No importa cuán terrible fue el código de batalla, las pruebas se pueden hacer de manera competente y hermosa. Por supuesto, un código mal diseñado genera pruebas feas, pero aún así se puede hacer un orden de magnitud mejor que el código en sí.
• Refactorización más frecuente. Los cambios en las pruebas son mucho menos peligrosos, por lo tanto, se acuerdan con más frecuencia. Esta es una buena oportunidad para trabajar en errores y practicar la escritura de código limpio a través de la refactorización.
• El desarrollo del pensamiento crítico. Las pruebas automáticas son una búsqueda interesante de cómo descifrar el código de otra persona. Además, la búsqueda no es estúpida, no se asoma y se mete, sino con la ayuda de la lógica, la combinatoria y la capacidad de ver vulnerabilidades. Además, una vez creado, un cheque continuará funcionando para usted constantemente.
• Desarrollando la capacidad de probar código. En el entrenamiento de combate cuerpo a cuerpo, a menudo dan palabras introductorias: "ahora solo trabajamos con nuestros pies; ahora solo trabajamos con nuestras cabezas". El uso de un solo mecanismo (en nuestro caso, pruebas automáticas) le permite perfeccionarlo para dominarlo.
• Menos cantidad de rumores. Los SDET se extraen mucho menos durante el fin de semana. No tienen que ir a trabajar urgentemente para corregir errores críticos. Bueno, tienen muchas menos posibilidades de cometer un error grave.

Contras de trabajar con SDET:

• Baja complejidad de codificación. El código de prueba suele ser aún más simple que el código de batalla. Condiciones previas, invocar el código de batalla, condiciones posteriores, etc. para cada prueba. El código para crear el entorno es más complicado, pero aún no llega al combate. Selección de algoritmos óptimos, diseño de estructuras de datos complejas, construcción de jerarquías de clases, generalmente todo esto lo pasa el desarrollador de la prueba.
• La experiencia está ganando más lentamente . La variedad y complejidad de situaciones en las que cae el desarrollador de la prueba es mucho menor. Falla en la línea de ensamblaje, pruebas rojas, a veces vuelcos: este es el conjunto principal con el que generalmente tiene que trabajar. El desarrollador tiene muchos más problemas floridos: comienza con variaciones de enlace y ensamblaje, continúa con fallas en un cliente en particular y volcados diseñados, y termina con la búsqueda de errores en el compilador y en las bibliotecas de terceros. Y no solo ...
• Una gran diferencia en el estilo de prueba con los desarrolladores. Por lo general, las SDET prefieren pruebas expresivas compactas que le permiten crear un entorno complejo en solo unas pocas líneas, y las comprobaciones atómicas en el estilo son iguales / no iguales (es decir, el requisito se cumple o no). A veces se trata de su DSL. Simplemente, los desarrolladores prefieren las pruebas con un ajuste fino del entorno y numerosas pruebas de varios aspectos del comportamiento del programa, lo que conduce a pruebas bastante múltiples. A veces se trata de copiar y pegar (que incluso los mejores desarrolladores no consideran pecado en este caso). Aquí puede discutir durante mucho tiempo la mejor manera o incluso escribir un artículo separado, pero el hecho es que cuando un desarrollador intenta modificar las pruebas SDET (o viceversa), esto a menudo conduce a discusiones largas e ineficaces.
• A continuación se muestra el "grado". Quizás debido a un código más simple y menos responsabilidad, pero en última instancia no es importante. Por lo general, es así.
• Más difícil moverse a una nueva posición. SDET bien puede tener la pregunta en la frente: ha estado escribiendo pruebas durante tanto tiempo, es decir, de hecho, simplemente llamó funciones y comparó los resultados: ¿puede escribir código real? ¿Conoces todas las trampas del idioma? ¿Resolviste problemas complejos? ¿Tuviste que desmontar errores ornamentales o vertederos? ¿Hay alguna experiencia con multihilo? ¿Tienes, después de todo, ambiciones?

Resumen 2

Como persona que trabajó como desarrollador durante muchos años, luego asistió a SDET durante varios años y luego volvió al desarrollo nuevamente, puedo decir lo siguiente.

Recomiendo gastar un SDET durante al menos un año o dos. Esta es una experiencia muy gratificante para cualquier desarrollador. Pero quedarse allí, en mi opinión, no vale la pena.