Agregando un comando para coverage

Si recibes este error:

sh: 1: open: not found

En Ubuntu se debe remplazar el comando OPEN que se usa en MAC OS.

"nyc report --reporter=html &&  open coverage/index.html"

Por el comando xdg-open que se usa en Linux.

"nyc report --reporter=html &&  xdg-open coverage/index.html"

En Windows con WSL2 (Ubuntu 20.04) tenía el siguiente error con el comando npm run report:

sh: 1: open: not found

Para ello la solución fue usar wslview en lugar de open:

"report": "nyc report --reporter=html && wslview coverage/index.html"

si no te funciona el comando “report” en windows usa el siguiente

"report": "nyc report --reporter=html &&  cd coverage && index.html"

Alguien más tuvo este error:
“open” no se reconoce como un comando interno o externo…

82.44% de test.
Repositorio personal

No logre testear el catch de las rutas por eso no logre un 100% de statements de estas y aún falta el test de los middlewares

Que interesante toda la parte de coverage, sin duda, buenas prácticas para aplicarlas en proyectos futuros.

Para los que están en linux pueden usar xdg-open en lugar de open, de la siguiente forma:

"report": "nyc report --reporter=html && xdg-open coverage/index.html"

Que gran herramienta!!!

Aumentando coverage a un 71.43%

Esa grafica de cobertura solo me dará estrés el no llegar al 100% no podría dejarlo :S

Por si a alguien le sirve la información, en windows el comando open es start en la cmd asi que use:

"report": "nyc report --reporter=html && start coverage/index.html"

Y me funciono bien

Para las personas que tienen Windows, este es el script que me sirvio:

"report": "nyc --reporter=lcov --reporter=text npm run test & start coverage/lcov-report/index.html"

Y estos son todos los scripts que tengo:

"scripts": {
    "dev": "set DEBUG=app:* & set NODE_ENV=devolepment & nodemon index",
    "start": "set NODE_ENV=production & node index",
    "test": "set NODE_ENV=devolepment & mocha --exit",
    "cover": "nyc npm run test",
    "report": "nyc --reporter=lcov --reporter=text npm run test & start coverage/lcov-report/index.html"
  },

Espero que les sea de utilidad

este coverage funciona con otros lenguajes?

hacer pruebas automatizadas permite agilizar el desarrollo… y cumplir con los tiempos de entregas establecidos…

muy buena

Los test sirven para certificar la calidad del producto, también.

que genial esto!

• Comando de covarage, nos permite identificar donde estamos fallando y como lo podemos corregir.

npm i -D nyc

"scripts":{
	...
	"cover": "nyc npm run test"
	"report": "nyc report --reporter=html && open coverage/index.html"
}
...
"nyc": {
	"all": true
	"include": ["route", "services","lib","utils"]
}

Para los alumnos que estén utilizando el CMD de windows y reciban el siguiente error:
‘open’ is not recognized as an internal or external command

deben reemplazar el comando open por el comando start en su script de report. Quedaría así:

"report": "nyc report --reporter=html &&  start coverage/index.html"

Este curso es ORO!! ❤️

Para testear el catch lo que hice fue comentar la linea del await para que no diera la respuesta, porque solo dejando el throw new error, no llegaba hasta el status, no se si alguien me explica como hacer un test correcto para ambos casos (respuesta y catch)

✌

Si tienen problemas con el script report debido a que open no se reconoce como un comando y están en Windows pueden cambiar open por start.

nyc report --reporter=html && start coverage/index.html

Esta increíble !! un poco complejo pero bueno jaja 😄

Así yo coloque en report

 "scripts": {
    "dev": "DEBUG=app:* nodemon index",
    "start": "NODE_ENV=production node index",
    "test": "mocha --exit",
    "cover": "nyc npm run test",
    "report": "nyc report --reporter=html && cmd.exe /C start coverage/index.html"
  },

Wow, genial!!

alguien pudo resolver con peticion get a un Id?

aqui mi codigo, pero me responde con 301

    describe('GET /movies/:movieId', function () {
        
        it('should respond with status 200', function (done) {
            var movieId = '55419c54bad54b35a9cb32e64c949102/'
            request.get('/api/movies/' + movieId )
                .expect(200, done);
        });```

Ya implemente los demas test, pero me queda la duda, como los implemento para los middleware de error?

Para quienes están preocupados por no haber probado los Middleware les comento que nada de nervios:

1. Sí hemos probado los Middleware de forma implícita cuando creamos los tests de las rutas. Ahí se probaron, y notarlo es fácil. Solo deben hacer un llamado a la consola con algún log y lo verán en la terminal al probar las rutas.
2. El coverage nunca debe ser un número que persigamos de forma enfermiza. Tener código funcionando de acuerdo al requerimiento del cliente sigue siendo lo más importante. Es bueno tenerlo por encima del 80%, pero no todo archivo lo requiere, más cuando acá vemos que precisamente el Middleware parece requerir ser testeado explícito para que el coverage entienda que sí entramos ahí.

uff mucho que experimentar con test!

Repositorio de la clase:
https://github.com/glrodasz/platzi-backend-node/tree/agregando-un-comando-para-coverage

Test del Post

describe.only('POST /movies/', function() {
        it('Should respond with status 201', function(done) {
            request.post('/api/movies').expect(201, done)
        })
        
        it('Should respond with the movie created id', function(done) {
            request
                .post('/api/movies')
                .end((err, res) => {
                    assert.deepEqual(res.body, {
                        data: moviesMock[0].id,
                        message: 'movie created'
                    })
        
                    done()
                })
        })
    })```

Necesito ayuda a la hora de hacer el test me dice: Error: expected 200 “OK”, got 500 “Internal Server Error”

describe('GET /movies/:movieId', function(){
    const movieId='5ef7b79b171644221a91c680';
    it('should respond with status 200', (done) => {
      request.get(`/api/movies/${movieId}`)
      .expect(200, done);
    })
  });

Veo mucho estrés por delante jaja pero a darle con los test

Me hubiese gustado que hiciera al menos el testing de los middlewares ya que se hacen completamente diferente por las utilidades que agrego ( joi y boom ) mal en esa parte, un video mas solo para esto no fuese caido mal y subimos el coverage que hoy en dia, mucho lo que se pide de testing

Este profesor hace todo en mac y los que usamos otros SO nos cagamos

routes.movies.test.js

movies.js

Me tiro este error:

<Couldn't get a file descriptor referring to the console
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! movies-api@1.0.0 report: `nyc report --reporter=html && open coverage/index.html`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the movies-api@1.0.0 report script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.>

Yo estoy usando Ubuntu como subsystem de windows. y me funciono de esta manera:

<   "report": "nyc report --reporter=html && cmd.exe /C start coverage/index.html">

no me reconocía el “wslview” en el comando report, pero lo solucioné con esto

"report": "nyc report --reporter=html && cmd.exe /C start coverage/index.html"

les dejo la Documentacion de nyc por si algo cambia con el tiempo.

aca enlace a npm: npmjs.com/package/nyc

Me gusto este tema “Coverage”.

interesante la herramienta para hacer reporting y el coverage de nuestros test

El comando para abrir el reporte en chrome desde windows

 start coverage/index.html

win10 subsystem ubuntu 20.04 funciona este es de otro compañeroque ya habia comentado

"coverage:report": "nyc report --reporter=html && cmd.exe /C start coverage/index.html",

😐😥😣

Me exploto la cabeza !! 😃 Pero hacer test esta genial para probar nuestros proyectos…

A mi me sirvio este script :

"scripts": {
    "dev": "DEBUG=app:* nodemon index",
    "start": "NODE_ENV=production node index",
    "test": "mocha --exit",
    "cover": "nyc npm run test",
    "report": "nyc report --reporter=html && cmd.exe /C start coverage/index.html"
  },```