¿Debemos probar una versión de código con otra

7

Debo escribir pruebas para una API en el trabajo para asegurarme de que no la rompamos a medida que desarrollamos en ella. Hasta ahora, las soluciones que se presentan son las siguientes:

  • El código "prod" y el código "devel" se ejecutan en la misma base de datos (con un volcado de la base de datos de producción);
  • El código "prod" y el código "devel" se ejecutan en su propia base de datos.

Ambas soluciones requieren una aplicación independiente para hacer una diferencia de los resultados dados por ambos códigos. Por lo tanto, también debo escribir algo que permita hacer diferencias entre JSON, XML o cualquier otro formato utilizado por la API.

En mi opinión, esto es pensar demasiado. Creo que sería mejor escribir pruebas funcionales simples que pasen con éxito y que se incluirán en el proyecto de código API. A medida que nos desarrollamos, simplemente ejecutaremos las pruebas y corregiremos lo que falló pasando como lo hizo anteriormente.

Mi compañero de trabajo había rechazado mi solución por no ser correcta ni eficiente por algunas razones:

  • necesitamos datos reales;
  • crear un conjunto de datos para las pruebas es imposible;
  • no queremos reescribir las pruebas cada vez que cambiamos algo;
  • necesitamos generar miles de urls al azar;
  • aunque no sé qué puede o no puede hacer PHPUnit, creo que algo escrito en bash estará más optimizado, o Python para aprovechar las ventajas de los subprocesos múltiples (!?).

Para mí, esto parece completamente sin sentido y pierde totalmente el propósito de las pruebas. En primer lugar, nuestro esquema de base de datos es bastante simple: una puntuación de tablas desnormalizadas con un puñado de columnas, muchas de ellas son de tipo booleano. Por lo tanto, escribir un conjunto de datos relevante me parece bastante simple.

En segundo lugar, creo (puedo estar equivocado) que las pruebas tienen que ver con determinar qué se supone que debe hacer su código en cualquier posible circunstancia. No hay necesidad de escribir más de unos pocos URL "codificados" (no generados de forma aleatoria al menos) urls que pondrán a prueba cada uno de esos casos.

En tercer lugar, las pruebas de reescritura como el comportamiento del cambio de código SE REQUIEREN y son un beneficio por sí mismas, no algo que se debe evitar porque parece ser algo natural.

Finalmente, mis pensamientos también están motivados por el hecho de que, por lo que el autodidacta sabe, nunca he oído hablar del tipo de prueba que quieren que escriba. Para mí, esta es una pista de que estamos hablando de algo realmente específico que requiere una solución aún más específica (pero nuestra API es bastante simple y principalmente de solo lectura), o de que nos estamos equivocando. Mi compañero de trabajo, que es el que más confía en mi superior, no parece estar muy versado en las pruebas ... alguna vez me reprenden por intentar aclarar que lo que ellos llaman "pruebas de unidad" en realidad es algo entre la integración y las pruebas funcionales con una enorme Sabor a humo (sí, en serio), y que deberíamos dejar claro qué queremos probar para qué propósito, o que no debemos probar métodos privados. Contestó con enojo que sus pruebas funcionan y que me estoy volviendo "demasiado teórica" y no debería escuchar a "las personas que aman las palabras de portmanteau" porque es inútil ... Dicho esto, simplemente no confío en él, en al menos este punto!

¿Alguna vez alguien tuvo que escribir pruebas que realmente eran las mejores soluciones? ¿Por qué fue la mejor? ¿Debo intentar aclarar mi punto de vista y / o atrapar a mi superior para que "obligue" a probar mi "solución básica" primero?

Gracias,

    
pregunta Shirraz 30.01.2017 - 10:20

1 respuesta

6

El tipo de prueba que describe definitivamente existe. Es una forma especial de prueba de regresión, y como tal se asegura de que su versión de desarrollo se comporte de manera idéntica a la versión prod, es decir, que no introduzca ninguna incompatibilidad hacia atrás.

Se usa con mayor frecuencia cuando se hacen reescrituras o clones de software existente, para asegurar que los comportamientos sean una coincidencia perfecta. Por ejemplo, el equipo de Samba tiene una variación de esto: la máquina de prueba tiene dos tarjetas de red, una tarjeta de red está conectada a un servidor de Windows, el otra tarjeta de red está conectada a un servidor Samba. La máquina de prueba envía comandos idénticos al azar a ambas máquinas y compara las respuestas. Cada vez que detecta una diferencia entre las respuestas, inicia una búsqueda de seguimiento para intentar encontrar la secuencia más simple de comandos que aún genera las diferentes respuestas, y luego registra esa secuencia junto con las dos respuestas en una base de datos para que un humano pueda echar un vistazo. en.

Por lo tanto, el caso de uso típico para este tipo de pruebas es cuando en realidad no sabe qué hace la versión con la que está realizando la prueba, ya sea porque se trata de un sistema heredado mal documentado (en el reescribir el caso) o porque pertenece a otra persona (en el caso de Samba que intenta ser compatible con el caso de Windows).

El marco Merb utilizó pruebas de aceptación para definir las API públicas (es decir, las API en las que las aplicaciones pueden confiar) y semi-público Las API (es decir, las API en las que pueden confiar los componentes internos de Merb) y las distinguen de las API privadas (que pueden cambiar sin previo aviso). Estas pruebas se dividieron en directorios diferentes y hubo reglas claras sobre lo que se le permite hacer con esas pruebas durante un ciclo de lanzamiento. Por ejemplo, no se le permite eliminar o modificar pruebas en el directorio público, solo agregue nuevas a menos que se haga una versión principal. (O, interpretado al revés: modificar o eliminar una prueba en el directorio público es un cambio incompatible con versiones anteriores en la API pública y esto requiere una nueva versión principal).

Algo así parece más aplicable a su situación: un conjunto de pruebas de aceptación que describen la API pública para sus clientes, un conjunto de pruebas de aceptación que describen las API internas para sus desarrolladores y, por supuesto, pruebas funcionales para segmentos individuales de funcionalidad. , pruebas unitarias para unidades de comportamiento individuales, pruebas de integración para puntos de comunicación individuales entre unidades de comportamiento.

Las pruebas API públicas también se pueden usar como pruebas de regresión. Cuando lanza una nueva versión, puede ejecutar las pruebas de la versión anterior contra la nueva, para ver si ha roto algo y qué ha roto, de modo que puede documentarlo (si es una incompatibilidad prevista) o arréglalo.

    
respondido por el Jörg W Mittag 30.01.2017 - 12:07

Lea otras preguntas en las etiquetas