Mocha: - opción de pedido para pedido de prueba aleatorio?

meh, es bastante fácil evitar las dependencias de pruebas cruzadas sin la ayuda de herramientas

Si bien es fácil to avoid cross-test dependencies without help of tooling , también es fácil agregar una dependencia de este tipo en un conjunto de pruebas sin darse cuenta. Un error en el conjunto de pruebas generalmente se traduce en un error en un sistema probado. Estos errores son difíciles de rastrear, ya que el código supuestamente está cubierto por pruebas.

Es imposible probar la ausencia de dependencias de prueba cruzada sin herramientas.

@visionmedia , reconsidere.

+1 @yanovich. Usaría una opción de orden aleatoria que genera un número de semilla. Esto sería muy útil en un entorno de CI.

@visionmedia , los modelos de mangosta proporcionan un ejemplo sencillo de dependencias de pruebas cruzadas. mongoose.model 'User', UserSchema agrega un modelo a la matriz de mongoose.models . Por tanto, es posible crear un archivo que se base en el modelo de usuario que se carga en mongoose.models. Tome Comment.find().populate('_user').exec(cb) como ejemplo. Si la prueba del usuario se ejecuta antes de la prueba del comentario, esto se ejecutará bien, porque presumiblemente require('./models/user') (o algo), ha cargado el modelo de usuario en mongoose.models. Pero si la prueba de comentarios se ejecuta antes de la prueba del usuario, obtendrá este error Schema hasn't been registered for model "User" . Esto podría suceder en producción cuando la API de comentarios se ejecuta antes que la API de usuario y el archivo de comentarios no sabía que tenía una dependencia entre archivos.

Es posible que aún tenga el problema de producción con la prueba funcionando si el archivo de prueba requiere ('./ modelos / usuario') (o lo que sea) y eso carga al usuario en mongoose.models. Sin embargo, tener un orden aleatorio sería una herramienta más útil para descubrir problemas potenciales como este.

Espero haberlo articulado bien. Esperamos escuchar su opinión.

lo siento, creo que es una exageración importante, el moca está lo suficientemente hinchado como está. Si hubiera mucho más interés, quizás valdría la pena la carga de mantenimiento.

Gracias por pensarlo.

Como la mayoría de las cosas en el código, es fácil para las personas que saben evitar hacer esto intencionalmente. Es más difícil evitar hacerlo sin querer. Y si ni siquiera sabe que es un problema (es decir, equipos de experiencia mixta), es muy probable que suceda :)

Parece que algunas personas están interesadas en él (y muchos piensan que es una de las mejores características de minitest). Si se fusionara, estoy feliz de implementarlo.

+1 interesado.

¡Sería bueno tenerlo! Encontré que mis pruebas fallaron al cambiar el nombre de los archivos, uf.

+1 esto es importante

: +1:

: +1:

+1 Esta es una deficiencia bastante grande.

La semántica de rspec es bastante sólida: puede pasar una semilla de orden o puede elegirla al azar. Si elige la semilla al azar, la imprime, por lo que es fácil de reproducir.

A menudo, no es tan fácil evitar las dependencias de pruebas cruzadas. A veces debido a interacciones globales imprevistas, a veces por conveniencia. Sospecho que más del 50% de los proyectos que usan mocha verían fallas en las pruebas si el orden fuera aleatorio. Aquí hay un par de ejemplos que parecen depender del orden de ejecución de la prueba:

https://github.com/visionmedia/mocha/blob/master/test/hook.async.js#L95
https://github.com/visionmedia/superagent/blob/master/test/node/not-modified.js#L31

Estos dos se enumeran como conjuntos de pruebas ejemplares en http://visionmedia.github.io/mocha/ y no pasé mucho tiempo buscando problemas.

Volveré a abrir esto. Creo que sería útil. Si bien hay formas de determinar departamentos de pruebas cruzadas sin herramientas, si podemos automatizar eso, las personas ahorrarían tiempo.

Después de jugar un poco con esto, parece no trivial debido a la naturaleza jerárquica de Suites. Las pruebas se ejecutan recurriendo a Suites. Para ejecutar _Tests_ aleatoriamente, tendríamos que enumerarlos, aleatorizarlos y luego trabajar al revés.

Esto haría que los Hooks before() y after() carezcan de sentido, ya que se ejecutarían _n_ veces por _n_ pruebas en una Suite (o más bien, en el _peor_ caso, pero solo si tenemos cuidado ), ya que cambiamos continuamente de contexto. Parece que incurrirá en una penalización de rendimiento.

Usar semillas aleatorias y reportar semillas autogeneradas parece trivial, sin embargo, los reporteros pueden necesitar conocer esta información, por lo que requiere implementación (s) en los reporteros.

Por supuesto, supongo que lo que he descrito aquí es lo que se pide. Una característica como esta necesita una especificación.

Otras opciones incluyen "Aleatorizar Suites" o "Aleatorizar pruebas dentro de Suites" o alguna combinación de las dos. En términos prácticos, esto significa que una vez que esté en un bloque describe() _A_, no podrá ejecutar pruebas en ningún bloque padre o hermano describe() _B_ hasta que se hayan ejecutado todas las pruebas en _A_ (que parece ser una implementación mucho más sencilla y no causará molestias con before() / after() ).

Lo que estoy pidiendo (y creo que otros) es la más simple de las opciones:

• aleatorizar las pruebas en el nivel más bajo: dentro de un solo bloque de descripción; baraja las declaraciones "it".
• Aleatorizar el orden de las suites de nivel superior (o aleatorizar el orden de los archivos que se cargan)

No creo que tenga mucho valor barajar las cosas en los niveles intermedios.

Ciertamente un truco, pero funciona para el nivel más bajo https://github.com/syrnick/mocha/compare/random_order?expand=1&w=0

mocha - fail
connect - pass
superagent - fail
express - pass** 
websocket.io - pass (can't tell for sure)

** Obtuve 2 fallas intermitentes de 100 ejecuciones de todo el conjunto de pruebas de cualquier manera.

¡De acuerdo, eso es ciertamente más fácil de implementar!

Estaba buscando en la biblioteca seedrandom para esto; use la opción pass .

Aceptaría PR.

Probablemente limpiaré ese código y ajustaré el conjunto de pruebas durante los próximos días. ¿Es el subrayado una dependencia demasiado pesada para esto? Probablemente podría usar algo ligero como esto: http://stackoverflow.com/questions/6274339/how-can-i-shuffle-an-array-in-javascript.

@boneskull Apoyo tu decisión de reabrir esto. : +1:

Otras opciones incluyen "Aleatorizar Suites" o "Aleatorizar pruebas dentro de Suites" o alguna combinación de las dos.

Me parece más que suficiente. No es necesario repetir todo el camino hacia abajo, enumerar y mezclar.

Es bueno escuchar que esto está entrando.

Me pregunto si rspec ha manejado la reproducción aleatoria recursiva. Podría valer la pena mirar
en su código?

El martes 26 de agosto de 2014, Joshua Appelman [email protected]
escribió:

@boneskull https://github.com/boneskull Apoyo tu decisión de
reabrir esto. [imagen:: +1:]

Otras opciones incluyen "aleatorizar suites" o "aleatorizar pruebas dentro de
Suites "o una combinación de los dos.

Me parece más que suficiente. No hay necesidad de recurrir hasta el final
enumerar y mezclar.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/visionmedia/mocha/issues/902#issuecomment -53482124.

@syrnick No quisiera aceptar un PR con una dependencia tan grande, y en su lugar usar seedrandom . Sin él, no estoy seguro de cómo apoyará la siembra. seedrandom permite especificar una semilla o no, y si no lo hace, le devolverá una semilla. Luego podríamos mostrárselo al usuario y permitirle que lo especifique, a la RSpec.

@syrnick Tenga en cuenta que si genera semillas, es posible que no se puedan "visualizar" sin

+1

No he mirado la implementación, pero +1 a la ejecución de prueba ordenada al azar por defecto es muy importante.

@syrnick Por favor, avíseme si tiene la intención de hacer esto, gracias.

Estoy feliz de hacer eso, pero no tengo una ETA inmediata.

: +1: ¿todavía necesitan ayuda con un PR?

De hecho, nadie parece haber comenzado a trabajar en esto.

Primero, parece que una mezcla de Fisher-Yates haría el trabajo aquí.

En segundo lugar, prefiero tener --order random , --order random-suites y --order default como los tres argumentos, con un :<seed> opcional.

+1. Acabo de encontrar un error que habría aparecido hace mucho tiempo si las pruebas fueran aleatorias. Similar a cómo RSpec lo admite.

Aquí hay un código que ilustra la utilidad del orden de prueba aleatorio. Si bien hay ejemplos más simples, este es uno que acabo de encontrar durante una demostración de TDD. Si invierte el orden de las pruebas, la primera prueba siempre falla.

game.js:

var express = require('express');
app = exports.app = express();

var sum = 0;

app.post('/bowl/:pins', function(req,res) {
    var score = parseInt(req.params.pins);
    console.log('Bowled ' + score);
    sum += parseInt(req.params.pins);
});

app.get('/score', function(req,res) {
    console.log('Sum: ' + sum);
    res.send(sum + '');
});

app.listen(process.env.PORT || 3000);

test \ gameTest.js:

var request = require('supertest'),
    should = require('should'),
    game = require('../game.js').app;

describe('a game of bowling', function() {
    describe('a gutter game', function() {
        it('should score 0', function(done){
            request(game).get('/score').expect(200, '0', done);
        });
    });

    describe('a single pin game', function() {
        it('should score 20', function(done){
            for(var i = 0; i < 20; i++) {
                request(game).post('/bowl/1').expect(200, done);
            }
            request(game).get('/score').expect(200, '20', done); 
        });
    });
});

Me encantaría tener esto.

: +1:

Una vez que involucre algunos globales (esto es Javascript, recuerde), comience a eliminar las llamadas al servidor e inserte / elimine cosas del DOM en sus pruebas, es _muy_ fácil agregar dependencia de pedidos. Aleatorizar el orden de prueba ayudaría a descubrirlos antes que después.
: +1:

: +1:

: +1:

+1

El orden aleatorio por defecto, con una semilla opcional para recrear el orden, sería una gran característica.

+1 para tenerlo, mis pruebas fallan en algún momento cuando se ejecutan en orden aleatorio ...

Mientras tanto, unix al rescate (Desafortunadamente, la semilla aleatoria no es compatible):

mocha `ls -1 test/*.js | sort --random-sort `

Estaba buscando en Google el orden en el que mocha ejecuta las pruebas y encontré esto. En ausencia de aleatorización, ¿cuál es el orden de ejecución predeterminado? ¿Es siempre el orden en el que aparecen físicamente las pruebas en el archivo?

: +1:

@danielabar, sí, estarán en el orden en que aparecen en el archivo.

@NicolasJacob bueno, la semilla aleatoria es realmente posible hasta cierto punto, por cierto. :)

$ seq 10 | shuf --random-source=<(yes 2883)
1
7
3
4
6
2
10
5
9
8

https://github.com/bahmutov/rocha funciona para esto.

@boneskull, si bien este es un problema antiguo, ¿la etiqueta PR Please sigue siendo válida? Si es así, recibiré una contribución al día siguiente.

Creo que en la búsqueda de eventualmente tratar de mantener el núcleo de moca al mínimo, el equipo podría dudar en introducir muchas características nuevas. La próxima gran versión de mocha tiene el objetivo de tener una interfaz conectable.

¿Puedo sugerir simplemente usar https://github.com/bahmutov/rocha si funciona?

Salsa impresionante

¿Qué quieres decir con interfaz enchufable? ¿Será posible introducir un orden de prueba aleatorio a través de esta interfaz?

+1 para la solicitud de función

@sulabhjain ,

Avances en esta rama .

+1 para esta función

Esta es realmente una de las características más críticas de un marco de prueba para ayudar a mantener las pruebas independientes. Todos los principales marcos de prueba de JVM tienen esta característica básica.

+1 para esta función. Sí, es fácil evitar las dependencias de prueba con suficiente experiencia y / o trabajando solo, pero no siempre es así.

Para aquellos interesados ​​en esta función, pueden enviar RP contra la rama de aleatorización para ayudar a terminar lo que queda.

+1 para la función. Realmente aprecio que una sucursal esté en progreso para esto.

Todavía esperando esto :))

Esto puede resultar muy útil.
@tj Entiendo que es fácil evitar las dependencias de pruebas cuando se trabaja con personas con algunas habilidades básicas sobre pruebas, pero a veces es necesario hacerse cargo de un equipo de desarrollo y puede chocar con personas que ni siquiera tienen conocimientos básicos sobre casos de prueba.

De hecho, esto también es útil cuando se hace cargo de proyectos existentes y desea verificar fácilmente si una prueba está vinculada a la anterior.

@boneskull ¡

Solo quería compartir mi solución temporal que uso para ejecutar pruebas de moca en orden aleatorio. Quizás sea útil para alguien.

mocha $(find tests/ -name *.spec.js | shuf)

Desafortunadamente, eso no mezcla ejemplos de prueba dentro del mismo ejemplo, ¡pero sigue siendo bastante inteligente y útil!

+1 en apoyo de esta función

Esto todavía está sobre la mesa, pero necesita atención de no-yo.

Entonces, ¿qué queda realmente aquí? Por donde puedo empezar

Me encantaría ver eso implementado ❤️

Acabo de encontrar el paquete choma , que proporciona un complemento muy simple para que Mocha aleatorice el orden de las suites de prueba y los casos. Buena alternativa a la rocha, que se mencionó anteriormente. ¡Simple y me resuelve el problema!

Una alternativa sería ejecutar pruebas en paralelo:

• Karma (+ moca o jazmín) - karma-paralelo - en este momento no admite cobertura de código
• Mocha - mocha-paralelo-tests o mocha.parallel
• Broma - hace esto por defecto