Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protractor test coverage #193

Closed
pvdyck opened this issue Dec 12, 2016 · 10 comments
Closed

Protractor test coverage #193

pvdyck opened this issue Dec 12, 2016 · 10 comments

Comments

@pvdyck
Copy link
Contributor

pvdyck commented Dec 12, 2016

I would like to collect the code coverage of the protractor tests with Istanbul.

Inspiration could come from https://github.com/bennyhat/protractor-istanbul-plugin or https://github.com/r3b/grunt-protractor-coverage.

Also, take a look here => https://www.jujens.eu/posts/en/2015/Sep/25/code-coverage-istanbul-protractor/

And I offer a bounty !

Bountysource

@lathonez
Copy link
Owner

I'd begrudging integrate with an existing plugin, though I don't think it's actually useful.

I couldn't find any other plugins than the two you've referenced, neither of which seem to be maintained and one has been marked as abandoned. r3b's plugin looks like it could potentially work, but I'm not adding another build tool for this.

All that said, you're basically looking for someone to write a relevant istanbul plugin for protractor, which I'm not interested in either.

Thanks

@pvdyck
Copy link
Contributor Author

pvdyck commented Dec 13, 2016

Since I outsource the testing of an app based on your starter project, I find a lot of value in the difference in coverage that each test provide.

I don't need a plugin, I just need someone to provide the necessary configuration, probably adapt https://www.jujens.eu/posts/en/2015/Sep/25/code-coverage-istanbul-protractor/

I don't have the skills for it, that's why I propose a bounty.

By closing the issue, nobody can claim the bounty and I also loose it, so could you reopen it so that anybody can implement a pull request fulfilling the requirements ? No need to merge it to your code, it can stay on the PR branch.

Thanks

@lathonez
Copy link
Owner

Unit test coverage is very relevant, just not e2e testing imo. The point is the metrics don't mean very much.

I'll reopen it anyway and link it to the roadmap. Hope you find someone willing to do the work for the bounty.

@pvdyck
Copy link
Contributor Author

pvdyck commented Dec 13, 2016

Thanks !

@ravigupta87
Copy link

I have discussed this issue with many developers, and conclusion was there is no use covering report for integration test,
What is the point of covering code i.e. page.someBtn.click() that is actually called somewhere else?

Istanbul is a good option of covering code for Unit test.

@lathonez
Copy link
Owner

lathonez commented Jan 6, 2017

Completely agree

@pvdyck
Copy link
Contributor Author

pvdyck commented Jan 8, 2017

First of all, when using a CI and codecov, you can check if a merge request actually increase or decrease the overall coverage of your code.

If you only check the unit test coverage and the merge request is about usability (no a lot of code change), you will write a lot more integration test scenario. It is not only about the actual code coverage % but the difference in % when you add more code to your codebase.

This % reflects your confidence in your code, and your ability to use continuous deployment.

Also, when you merge all the the code coverage (integration, unit test,...) you can find blind spots, code where nobody goes, and think about the reason why it lies there in the first place and maybe remove it (the less code, the more quality). If you only have unit test coverage, you might not do it.

So, IMHO any kind of test code coverage is useful, especially linked to your CI and your merge request (and Codecov).

BTW, right now, I have testers working on integration testing because they don't know much about angular2 and they are learning typescript (they are not ready for unit testing yet).

What is the point of covering code i.e. page.someBtn.click() that is actually called somewhere else?

No point of course, you never actually collect coverage on your test scenario or unit test, you collect it on your production code.

@nekkon
Copy link

nekkon commented Jan 10, 2017

@pvdyck I need what you are asking for too. I will try to see if I can develop a solution

@pvdyck
Copy link
Contributor Author

pvdyck commented Jan 10, 2017

@nekkon Thanks ! Let me know if I can help.

@lathonez
Copy link
Owner

Sorry, I'm too OCD to leave this open. I also don't agree that it's useful. To maximise visibility of your bounty you should probably open something against protractor anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants