JSCover.log is blank after running my manual test on instrumented code

[pillal]

I instrumented the code,started running web server in proxy mode, started JSCOver as well and then started running few manual tests on the instrumented code. I see all the file structure getting created in the target folder. However, coverage is zero.

Could you let me know if I'm missing something here?

[tntim96]

JSCover.log is blank after running my manual test

Maybe your referring to jscoverage.json which holds the coverage data? JSCover.log will be empty if no logging occurred, and by default, only errors will be logged.

When you say "coverage is zero", you mean you opened jscoverage.html in a browser and the totals were 0?

[pillal]

Yes. You are right. I opened jscoverage.html and coverage is zero.

[tntim96]

I instrumented the code

Using file-system instrumentation?

started running web server in proxy mode

The JSCover proxy? If so there's no need to do the first instrumentation as the proxy will instrument the JavaScript on the fly (if not using SSL). If you are using the proxy, take a look at https://github.com/tntim96/JSCover/issues/116 for some useful links to get this working.

[pillal]

Hi,Before I wrote this mail I tried running the tests by instrumenting and then executing the tests. That did not work.

After your reply, I ran the tests against a fresh instance in proxy mode (Starting web-server and JSProxy) without file instrumentation. I get this error when I open the JSCoverage.html.

"Error: NetworkError: A network error occurred.".

Could you let me know how this issue can be fixed please?

These are the steps I followed:

1. Set localhost in firefox with 3128.
2. Started web-server.
3. Started JSCOver proxy.
4. After the tests, saw JSCoverage.html.

There was no coverage but saw the above error "Error: NetworkError: A network error occurred.".

Any help would be of a great help!

Thanks Balu

On Mon, Apr 7, 2014 at 2:36 AM, tntim96 notifications@github.com wrote:

I instrumented the code

Using file-system instrumentation?

started running web server in proxy mode

The JSCover proxy? If so there's no need to do the first instrumentation as the proxy will instrument the JavaScript on the fly (if not using SSL). If you are using the proxy, take a look at #116https://github.com/tntim96/JSCover/issues/116for some useful links to get this working.

Reply to this email directly or view it on GitHubhttps://github.com/tntim96/JSCover/issues/126#issuecomment-39711585 .

Cheers! Balasubrahmanyam P

[tntim96]

"Error: NetworkError: A network error occurred.".

Try starting chrome with the --allow-file-access-from-files switch.

[pillal]

I opened the file in firefox instead. The issue with "Error: NetworkError: A network error occurred.". is resolved. However, coverage still shows zero! :-(

[tntim96]

I tried running the tests by instrumenting and then executing the tests. That did not work. I ran the tests against a fresh instance in proxy mode...coverage still shows zero!

I have no way of determining what went wrong from the information you've provided.

Have you got the 'examples/localStorage-proxy' sample working?

You may need to save coverage results between tests and merge later, as I don't think even localStorage survives the WebDriver client closing. Also, check the jscover.log file for errors.

[pillal]

Hi,

Just a quick thing, if that helps...

We see a lot of traffic to our application through JSProxy, but cannot see any data in the JSON file after the test run. Am I missing something here?

[tntim96]

The jscoverage.json file should not be empty. It contains all the coverage data. Is the log file, jscover.log, empty?

Check that you can get the samples working, and/or try running just one of your tests. Also, you should be able to test the scenario manually to troubleshoot if your are having trouble finding the issue when automated.

[pillal]

I'm setting loglevel=FINEST when running the test. Hence JScover.log is not empty. If I leave the logging level to default, it would not show up any data. I tried manual testing option as well, it still shows zero on coverage.

[tntim96]

If I leave the logging level to default, it would not show up any data

That's good as it means there were no errors.

I'm setting loglevel=FINEST when running the test. Hence JScover.log is not empty

So inspecting that doesn't give you a clue as to what's wrong? It should log the URLs it is instrumenting (at INFO level in InstrumenterService). Maybe you can put the results somewhere for me to review.

I tried manual testing option as well, it still shows zero on coverage.

Again, I don't have enough information to solve this. Can you describe your setup with:

• the host and port of the web-server
• the host of the machine running the browser
• the host and port of JSCover
• the proxy settings you are using for your browser
• the URL you use to run one test
• the URL you use to view jscoverage.html to store the report (or if you are using the programmatic storage)
• whether you are using local-storage

[pillal]

Hi,

I'll try these options and let you know.

Thanks

On Fri, Apr 11, 2014 at 5:58 AM, tntim96 notifications@github.com wrote:

If I leave the logging level to default, it would not show up any data

That's good as it means there were no errors.

I'm setting loglevel=FINEST when running the test. Hence JScover.log is not empty

So that's not giving you a clue as to what's wrong? Maybe you can put the results somewhere for me to review.

I tried manual testing option as well, it still shows zero on coverage.

Again, I don't have enough information to solve this. Can you describe your setup with:

• the host and port of the web-server
• the host of the machine running the browser
• the host and port of JSCover
• the proxy settings you are using for your browser
• the URL you use run one test
• the URL you use to view jscoverage.html to store the report (or if you are using the programmatic storage)
• whether you are using local-storage

— Reply to this email directly or view it on GitHubhttps://github.com/tntim96/JSCover/issues/126#issuecomment-40200306 .

Cheers! Balasubrahmanyam P

[Manishr]

Hi,

Thanks for your help and suggestions! Greatly appreciate your help! After trying all the above options, I tried the sample example for running some of the JUnit tests I have. I've integrated the needed code into my infrastructure.

This is the challenge I have:

The test runs fine without JSCover. It does all the needed operations with minimal sleep time. However, when I start proxy for coverage and run my JUnit tests against the code, the system just crawls. I crashes in the middle of a test execution as it cannot locate the object. I'm running these tests on firefox.

Is there a fix that would help me run the tests without making any changes? Would highly appreciate!

Thanks again for helping! Real great work...

[tntim96]

Hi @Manishr, perhaps you should post to a new thread or are you working with @pillal?

[pillal]

Hi tntim96,

Yeah. Manishr works with me.

Could you provide a solution for the issue mentioned above please?

[tntim96]

I don't have enough information to solve this. Can you describe your setup with:...

I need a detailed response to this post above.

[pillal]

Sorry..My Bad. I should have given details about the issue Im running into.

My Set-up: Firefox driver, JUnit tests. Used WebDriverGeneralProxyTest.java to setup the infrastructure.

The issue I'm running into is that tests really crawl....when I integrate with JSCover. They work perfectly fine without coverage data. Because of this reason, lot of tests are failing as it takes a bit of time for objects to get displayed. Do you know of a solution that would make the execution smoother with coverage ON.

Thanks for your help!

[tntim96]

You haven't provided any of the points listed above that could assist in solving this. There could be several things wrong (e.g. you're not trying JSCover with SSL are you?).

WebDriverGeneralProxyTest.shouldRunExampleAndStoreResultProgrammatically works fine, so try to run just one of your tests similar to this to get started.

[pillal]

the host and port of the web-server localhost:3129 the host of the machine running the browser I'm using WebDriverGeneralProxyTest.java for running the tests. the host and port of JSCover the proxy settings you are using for your browser the URL you use to run one test the URL you use to view jscoverage.html to store the report (or if you are using the programmatic storage) JSCoverage.html is good with all the data coverage. whether you are using local-storage Yes. I'm using local storage.

I've solved all the issue with test execution. I have no issues there. I have only one issue right now, which is that it really runs pretty slow. I'm using the proxy mode to execute my tests.

No. I'm not running SSL with my tests.

[tntim96]

I have only one issue right now, which is that it really runs pretty slow

So you get non-zero coverage now?

[pillal]

Yes. I'm getting non-zero coverage.

On Apr 16, 2014, at 5:42 PM, tntim96 notifications@github.com wrote:

I have only one issue right now, which is that it really runs pretty slow

So you get non-zero coverage now?

— Reply to this email directly or view it on GitHub.

[tntim96]

OK, so if there are no errors in jscover.log, and your unit tests all pass (when there aren't time-out errors)...

It does all the needed operations with minimal sleep time

Make sure you use web-driver wait for condition rather than just thread sleeps.

JSCover will slow down things for a couple of reasons:

• The JavaScript is instrumented so will be slower to load and execute
• The proxy interception uses HTTP 1.0 which will slow things down

You can set logging to finest to see where the time is being spent for a minimal test-case. If you post jscover.log somewhere I could take a look.

[pillal]

Hi,

I've set the logging level to FINEST and attached is the log for your reference. Test fails in the middle of execution.

Could you let me know what change I can do to get the issue fixed?

On Thu, Apr 17, 2014 at 4:05 AM, tntim96 notifications@github.com wrote:

OK, so if there are no errors in jscover.log, and your unit tests all pass (when there aren't time-out errors)...

It does all the needed operations with minimal sleep time

Make sure you use web-driver wait for condition rather than just thread sleeps.

JSCover will slow down things for a couple of reasons:

• The JavaScript is instrumented so will be slower to load and execute
• The proxy interception uses HTTP 1.0 which will slow things down

You can set logging to finesthttp://tntim96.github.io/JSCover/manual/manual.xml#advancedLoggingto see where the time is being spent for a minimal test-case. If you post jscover.log somewhere I could take a look.

— Reply to this email directly or view it on GitHubhttps://github.com/tntim96/JSCover/issues/126#issuecomment-40703163 .

Cheers! Balasubrahmanyam P

[tntim96]

I've set the logging level to FINEST and attached is the log for your reference

I can't see any attachment. You need to upload the file somewhere and provide a link to it.

Could you let me know what change I can do to get the issue fixed?

I'll try with the logs (when provided), but the more you can isolate the issue and enable me to reproduce the issue, the more likely I'll be able to assist you in resolving it.

[pillal]

Hi,

Here is the link for the log. As I told before, test fails in the middle of the execution. However, it runs fine without coverage code.

http://www31.zippyshare.com/v/69304586/file.html

Thanks

[tntim96]

There's a bit too much logging. Can you cut it down with the following settings:

.level = SEVERE
jscover.level = FINEST

...also there is an error...

20140418 11:11:32.610,37,SEVERE,"Error on line 48 of /chrome/app/scripts/thrdprty/analytics/clientinsight.js",jscover.instrument.ParseTreeInstrumenter,
java.lang.NullPointerException
    at org.mozilla.javascript.Node.getChildBefore(Node.java:222)

...while I'd like to solve this, you probably want to exclude this from instrumentation with something like --no-instrument=/chrome/app/scripts/thrdprty

Will add further comments if I see anything else.

[tntim96]

Also found "Instrumenting /chrome/app/bower_components/sass-bootstrap/dist/js/bootstrap.min.js". You should review the log thoroughly and make sure you're only instrumenting the JavaScript source you want to instrument. You may want to make use of the --only-instrument-reg option.

[tntim96]

Also found "Header: Host: intuit.sp1.convertro.com". Make sure you add all hosts, other than the web-server you're testing, to the proxy bypass list.

[tntim96]

Also, Starting JSCover 1.0.7 HTTP Server, port 3129 appears twice in the log - not sure why.

[pillal]

How would I add proxy by-pass list programmatically: something like the server URL...

[pillal]

I tried all the options including... no-instrument as well as log level as severe, I see no luck! :-(. Test execution crashes in the middle of a test run.

[tntim96]

How would I add proxy by-pass list programmatically

Something like:

        Proxy proxy = new Proxy().setHttpProxy("localhost:3129");
        proxy.setNoProxy("intuit.sp1.convertro.com,ocsp.verisign.com");

I tried all the options including... no-instrument as well as log level as severe, I see no luck!

Those changes are beneficial, but don't necessarily solve all your issues.

Changing the log level was to remove some of the extraneous logging - can you re-post the results?

Test execution crashes in the middle of a test run

Can you isolate that issue and perhaps make it available to me so that I can reproduce the issue? This would certainly speed up this process.

[pillal]

Hi,

Here are the latest logs: http://www8.zippyshare.com/v/48218943/file.html I can't see any errors in the log...

[tntim96]

You should review the log thoroughly and make sure you're only instrumenting the JavaScript source you want to instrument

I can still see you're instrumenting things you shouldn't be. For example:

• /chrome/app/bower_components/sass-bootstrap/dist/js/bootstrap.min.js
• /chrome/app/scripts/env.js

[pillal]

I've included the unneeded folders under "--no-instrument" parameter as part of args. It still shows up in the log. Not sure if it is actually instrumenting or not.

[tntim96]

It shouldn't show up in the log, so it could be a problem with JSCover in proxy-mode. I'll look into it.

[tntim96]

Had a quick look - --no-instrument in proxy-mode seems to be fine. Try a few variations of --no-instrument (what are you currently using?) until you can see something like the following in the logs:

20140423 12:08:55.816,23,FINEST,"Matched URI 'test/vendor/qunit.js' Pattern 'PatternMatcherString{pattern='test/vendor'}' Skip true",jscover.ConfigurationCommon,

...this shows that the pattern was matched and that instrumentation is to be skipped.

[pillal]

I checked all the logs to figure out the pattern match. All the unneeded code is NOT getting instrumented. Surprising thing is that the test passes successfully if I run it without coverage.

[tntim96]

All the unneeded code is NOT getting instrumented.

Maybe you have to show me the latest logs as well as the program arguments. The log I'm looking at has Instrumenting /chrome/app/bower_components/sass-bootstrap/dist/js/bootstrap.min.js, Instrumenting /chrome/app/bower_components/handlebars/handlebars.min.js as well as others which shouldn't be instrumented (i.e. they should be excluded with something like --no-instrument=/chrome/app/bower_components). Basically only your code (and not library or test code) should appear in your coverage report.

the test passes successfully if I run it without coverage.

Can the issue be isolated so that I can reproduce it?

[pillal]

Here is the latest latest log...

http://www60.zippyshare.com/v/47960927/file.html where /chrome/app/bower_components/sass-bootstrap/dist/js/bootstrap.min.js is not getting instrumented. The other file is getting instrumented... and here are the args[] I'm passing...

private final String[] args = new String[]{ "-ws", "--port=3129", "--proxy", "--local-storage", "--log=SEVERE", // "--log=FINEST", "--no-instrument=/chrome/app/scripts/thrdprty", "--no-instrument=/chrome/app/bower_components/sass-bootstrap/dist/js", "--no-instrument=/chrome/app/scripts/env.js", "--report-dir=" + getReportDir()

};

[tntim96]

OK, that looks a lot better.

You can probably replace --no-instrument=/chrome/app/bower_components/sass-bootstrap/dist/js with --no-instrument=/chrome/app/bower_components so that you also exclude /chrome/app/bower_components/handlebars/handlebars.min.js as well.

There also still seems to be some library code there (e.g. Mojo) and test code (e.g. abTest.js). Maybe try the approach described below:

Testing Suggestion To Eliminate JavaScript Instrumentation as a Cause Of Your Failing Test For testing purposes only, you can run the failing test with --no-instrument=/chrome which should ensure that no JavaScript gets instrumented. If the test still fails without any instrumentation occurring, then that points to there being a problem with the test and proxy interaction. If not, you can reintroduce instrumentation bit by bit to isolate the problem.

[pillal]

I'll try your suggestions and get back to you....

[tntim96]

Any update? BTW, there's a minor fix checked-in for a proxy content -length issue. To try it you can either build yourself, download a snap-shot I've built, or grab the latest maven snap-shot from here - NB this has to be combined with the Rhino JAR here.

[pillal]

I'll try the fix and let you know....

[tntim96]

Closing due to inactivity, but feel free to re-open if you have more information.