Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using Istanbul for integration tests against a Node microservice

Documentation is pretty sparse on doing coverage with istanbul for integration tests. When I run through my mocha tests, I get No coverage information was collected, exit without writing coverage information.

The first thing I do is instrument all my source code:

✗ istanbul instrument . -o .instrument

In my case, this is a REST microservice that is Dockerized which I have written Mocha tests to run against it to validate it once it is deployed. My expectation is istanbul will give me code coverage against the source from that Node service.

The second step I do this command to run node on my instrumented code:

✗ istanbul cover --report none .instrument/server.js

After that, I run my tests using the following from the my main src directory as follows (with results):

✗ istanbul cover --report none --dir coverage/unit node_modules/.bin/_mocha -- -R spec ./.instrument/test/** --recursive


  swagger-tests
    #createPet
      ✓ should add a new pet (15226ms)
    #getPets
      ✓ should exist and return an Array (2378ms)
      ✓ should have at least 1 pet in list (2500ms)
      ✓ should return error if search not name or id
      ✓ should be sorted by ID (3041ms)
      ✓ should be sorted by ID even if no parameter (2715ms)
      ✓ should be only available pets (2647ms)
    #getPetsSortedByName
      ✓ should be sorted by name (85822ms)
    #deletePet
      ✓ should delete a pet (159ms)


  9 passing (2m)

No coverage information was collected, exit without writing coverage information

When I run istanbul report, it obviously has nothing to report on.

What am I missing?

See develop branch of this project to reproduce issue.

like image 352
occasl Avatar asked Sep 26 '22 06:09

occasl


People also ask

What is Istanbul in Nodejs?

GitHub - gotwarlost/istanbul: Yet another JS code coverage tool that computes statement, line, function and branch coverage with module loader hooks to transparently add coverage when running tests. Supports all JS coverage use cases including unit tests, server side functional tests and browser tests.

How does Istanbul code coverage work?

Istanbul collects coverage by wrapping various functions inside the JavaScript language so that when your code is invoked, so too is Istanbul's monitoring code. By wrapping code the way Istanbul does, we are able to see coverage on a granular level, like which branches have been invoked.


2 Answers

The owner of istanbul helped me to resolve this. I was able to get things going by performing the following steps:

  1. Skip instrumenting the code; it's not needed
  2. Call istanbul with --handle-sigint as @heckj recommended and remove the flag --report none
  3. Once your server is up, just run tests as normal: ./node_modules/.bin/_mocha -R spec ./test/** --recursive
  4. Shutdown the server from step 2 to output the coverage
  5. View the HTML file in open coverage/lcov-report/index.html
like image 138
occasl Avatar answered Sep 28 '22 05:09

occasl


This looks like you were following the blog post I was just looking at when trying to figure out how to attack this time problem:

  • Javascript Integration Tests Coverage with Istanbul

I don't what specifically what is different between what you've posted above, and what that blog post identifies. One thing to check is to make sure that there are coverage*.json files getting generated when the code is being executed. I'm not sure when those files are specifically generated by Istanbul, so you may need to terminate the instrumented code running. There's also a mention of a --handle-sigint option on the cover command in the README that hinted at needing to invoke a manual SIGINT interupt to get coverage information on a long running process.

Looking at one of the bugs, there's obviously been some pain with this in the past, and some versions of istanbul had problems with "use strict" mode in the NodeJS code.

So my recommendation is run all the tests, and then make sure the processes are all terminated, before running the report command, and checking to see if the coverage*.json files are written somewhere. Beyond that, might make sense to take this as an issue into the github repo, where there appears to be good activity and answers.

like image 22
heckj Avatar answered Sep 28 '22 05:09

heckj