No coverage object in the browser

[peterhendrick]

Hi,

I noticed that issue 10 was closed a few months back, but a few people were still getting this problem and I have been unable to get passed it myself. I went ahead and reproduced the issue on my open source project. It's a mean.js template application and I've added grunt-protractor-coverage and it's dependencies. When I run the gruntfile, everything seems to work, protractor runs, the files are instrumented, but when the report comes out I get 100% coverage of zero files. I seperated the protractor gruntfile from the dev gruntfile and named it gruntfile-e2e.js. I am using Ubuntu 14.04.

You should be able to reproduce easily if you run these commands: ~$ git clone https://github.com/peterhendrick/openSource

Of course, install the package.json: ~$ cd openSource ~/openSource$ npm install

Update the selenium driver: ~/openSource$ ./node_modules/.bin/webdriver-manager update (I start up the driver before tests, so there's no need to start a server for the webdriver)

Start the app in a server (default is port 3000). You will need a mongodb instance to be running: ~/openSource$ npm start

Open another terminal and navigate to the app folder and run the e2e gruntfile to see the issue: ~/openSource$ grunt --gruntfile gruntfile-e2e.js

You should see the following near the end: "Running "protractor_coverage:local" (protractor_coverage) task Collector started on port 3001 Starting selenium standalone server... [launcher] Running 1 instances of WebDriver Selenium standalone server started at http://192.168.1.17:37079/wd/hub No coverage object in the browser. .

Finished in 4.716 seconds 1 test, 1 assertion, 0 failures"

If anyone could help me get passed this issue, it would be much appreciated.

Thanks,

Peter

[F1LT3R]

+1

[robertgroh]

@peterhendrick, from what I understand your are using your normal (NOT-instrumented) sources to start your server via npm start on port 3000. Then you run the default task of gruntfile-e2e.js which indeed runs the instrument task, which writes to instrumented and use these files do run the server via connect on port 9000. Then you run the proctrator_coverage task with the local target, which uses your NOT-instrumented server on port 3000 baseUrl: 'http://localhost:3000/.

As you don't use your instrumented server on port 9000 for your protractor coverage run, there will be no coverage object. I suggest to change your baseUrl to use the instrumented server and stop your normal server on port 3000 to avoid confusion.

[pranavvarshney]

I am also facing the same problem.

Running "connect:server" (connect) task Started connect web server on http://localhost:3000 Running "protractor_coverage:local" (protractor_coverage) task Collector started on port 3001 Starting selenium standalone server... [launcher] Running 1 instances of WebDriver Selenium standalone server started at http://10.40.240.66:59508/wd/hub No coverage object in the browser.

GruntFile.js

connect: { server: { options: { port: 3000, base: 'instrumented' } }, protractor_coverage: { options: { configFile: "./protractor.conf.js", // Default config file collectorPort: 3001, keepAlive: true, // If false, the grunt process stops when the test fails. noColor: false, // If true, protractor will not use colors in its output. coverageDir: 'coverage', args: { baseUrl: 'http://localhost:3000' }

    },
  local: {
    options: {
      args: {
        baseUrl: 'http://localhost:3000/',
        // Arguments passed to the command
        'browser': 'chrome'
      }
    }

  },
},

If anyone could help me get passed this issue, it would be much appreciated.

Thanks Pranav

[robertgroh]

@pranavvarshney when I got the message No coverage object in the browser. it was always caused by running the un-instrumented source code (either server-backend or client-side javascript in the browser). So I would suggest to double check your running server, that its running code itself is instrumented and that it serves the instrumented javascript-files (client-side) to the browser.

[DimoDimov]

I had the same issue. I fix my problem by setting relative path with my server. Because even if you instrument the server and move it with your static folder it will still look for the absolute paths instead for the relative.

Example:

if your node code looks like this:

app.use(express.static('./public'));

it should be changed to look like this:

app.use(express.static(path.resolve(__dirname, '../public')));

this way when your instrumented code is moved to a new 'instrumented folder' it will look for you instrumented 'public' directory relatively inside the 'instrument'.

What happens now is that you have you js files instrumented (C) and (D) which is totally what you need.

The problem begins when you run the server code (D) where absolute path points to (A) instead of (C). So you instrumented server runs the non instrumented front end. You fix this by setting the server to look relatively, not by absolute path.

/public (A) -> clean front end code /server (B) -> clean back end code /instrumented /public -> (C) instrumented front end code /server -> (D) instrumented back end code