Cucumber-js: Agregue particiones de trabajo personalizadas para el tiempo de ejecución paralelo.

Hmm, por lo que actualmente está usando una cola de encurtidos (un escenario o un ejemplo de un esquema de escenario), no características. Y parece que el objetivo principal es que no se ejecuten dos escenarios en conflicto al mismo tiempo. No debería importar a qué esclavo corrieran.

Pensamientos sobre una API como

const {setParallelCanAssignFn} = require('cucumber')

// testCase = {uri, pickle}
// runningTestCases = [{uri, pickle}, ... ]
setParallelCanAssignFn((newTestCase, runningTestCases) => {
  // return true if newTestCase can be alongside the currently running test cases, false otherwise
})

Luego, cuando un esclavo está libre, busca en la lista de encurtidos y le asigna el primero para el que esta función devuelve verdadero. La función predeterminada siempre devuelve verdadero.

¡Me gusta esto! Tengo muchos pequeños pensamientos ...

Definitivamente parece una opción más poderosa, sí. Tiene el efecto de equilibrar muy bien el trabajo entre los trabajadores de la piscina. En mi sugerencia anterior, tuve que estimar el costo de tiempo de ejecutar una prueba y traté de equilibrar las cosas; ¡no es tan eficiente o fácil como asignar a trabajadores inactivos!

También prefiero el uso de encurtidos: mi particionador funcionaba engullendo para encontrar archivos de características, cargándolos a través del analizador Gherkin y examinando los AST en busca de pasos relevantes, por lo que casi todo mi código recrea algunas de las partes internas del pepino. Ya que los tienes a mano y puedes pasarlos como parámetros, ¡eso me hace la vida mucho más fácil! :) Noto que esta API está cerca pero no es la misma que para los formateadores; en un formateador puedo escribir

    options.eventBroadcaster.on('test-case-started', ({ sourceLocation }) => {
        const { gherkinDocument, pickle } = options.eventDataCollector.getTestCaseData(sourceLocation);

¿Podría el caso de prueba pasado a la función obtener los mismos parámetros o estructura de caso de prueba ( { gherkinDocument, pickle } ) que los eventos del formateador? Estoy pensando en un caso simple en el que necesita realizar una partición basada en etiquetas (digamos @uses(DB1) que encontraría en el gherkinDocument. Además, una API similar puede significar menos documentación y más reutilización de código.

Solo para aclarar, el setParallelCanAssignFn estaría diseñado para ejecutarse en el maestro ('¿quién debería obtener el trabajo?'), En lugar de los esclavos ('¿puedo aceptar este trabajo?') Un implementador no necesitaría preocuparse por los subprocesos múltiples, ¿verdad, ya que el maestro tendría la responsabilidad exclusiva de un solo subproceso para asignar el trabajo?

También debería mencionar la secuencia de ejecución, creo. Este mecanismo le permite rechazar una prueba y luego aceptarla más tarde. Entonces, un archivo de características escrito

Feature: X
    Scenario: A
    Scenario: B

De hecho, podría ejecutarse en el orden [B,A] . Es probable que eso rompa el conjunto de pruebas de alguien en algún lugar del mundo. No es que debería, el orden de ejecución no debería importar, pero parece que la primera vez que pepino permitiría que el escenario se ejecute fuera del orden de los archivos de características.

De todos modos, ¡gracias por pensarlo!

¿Cuál es el estado actual de esta función? Me complace contribuir con tiempo para implementar un POC si me puede indicar la dirección correcta. Me gusta la idea de usar etiquetas en escenarios para definir qué recursos requieren un mutex para ejecutarse.

Hola,

Estoy en la misma situación de restablecimiento de la base de datos que @stevecooperorg y también me encantaría la capacidad de realizar pruebas en paralelo con etiquetas.

Al menos podría hacer un grupo "sin base de datos" y uno "usando base de datos".

¡Sí! También estoy realmente deseando esta funcionalidad. Voy a preparar un POC (a menos que algo esté entrando). Será mi primera contribución pública. Veamos cómo va eso. Supongo que primero examinaré rápidamente las pautas.

@ eman2673 Solo para informarle: resolví el problema paralelo iniciando una instancia por etiqueta CLI del host (scaleway para mí).

Absolutamente no pepino-js nativo, pero es muy eficiente y nos permite tener una prueba completa en cada fusión en master.
Y con este método, también podría hacer una instancia por archivo de prueba si quisiera.

@ adrien-carre Gracias por el aviso. Estoy buscando un poco más de control. Quiero poner a todos los trabajadores en todo y mágicamente solo trabajan en casos de prueba que no entran en conflicto en cuanto a recursos. También quiero poder etiquetar escenarios que utilizan múltiples recursos (generalmente 1 o 2 tablas). Intentando implementar el enfoque @charlierudolph mencionado anteriormente.