-
Notifications
You must be signed in to change notification settings - Fork 137
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
Comments
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 |
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 |
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. |
Thanks ! |
I have discussed this issue with many developers, and conclusion was there is no use covering report for integration test, Istanbul is a good option of covering code for Unit test. |
Completely agree |
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).
No point of course, you never actually collect coverage on your test scenario or unit test, you collect it on your production code. |
@pvdyck I need what you are asking for too. I will try to see if I can develop a solution |
@nekkon Thanks ! Let me know if I can help. |
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. |
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 !
The text was updated successfully, but these errors were encountered: