Merge lp://qastaging/~elopio/snapcraft/integration_coverage into lp://qastaging/~snappy-dev/snapcraft/core

Proposed by Leo Arias
Status: Merged
Approved by: Leo Arias
Approved revision: 96
Merged at revision: 97
Proposed branch: lp://qastaging/~elopio/snapcraft/integration_coverage
Merge into: lp://qastaging/~snappy-dev/snapcraft/core
Diff against target: 187 lines (+73/-15)
3 files modified
bin/snapcraft-coverage (+44/-0)
integration-tests/units/jobs.pxu (+11/-11)
runtests.sh (+18/-4)
To merge this branch: bzr merge lp://qastaging/~elopio/snapcraft/integration_coverage
Reviewer Review Type Date Requested Status
Michael Terry (community) Needs Information
Michael Vogt (community) Approve
Review via email: mp+265476@code.qastaging.launchpad.net

Commit message

Added coverage report to the integration tests.

To post a comment you must log in.
95. By Leo Arias

Removed extra newline.

Revision history for this message
Leo Arias (elopio) wrote :

I tried way to many things to get this working. I'm not totally happy with the approach, but it works. If you can think of a better way to do this, please leave a comment.

Revision history for this message
Michael Vogt (mvo) wrote :

Nice approach, I like it!

review: Approve
Revision history for this message
Michael Terry (mterry) wrote :

I'm fine with the approach of a second, coverage-enabled binary. But don't we want to combine the unit tests and integration tests for the coverage report?

review: Needs Information
Revision history for this message
Michael Terry (mterry) wrote :

(that is, have one report, not two)

Revision history for this message
Leo Arias (elopio) wrote :

> I'm fine with the approach of a second, coverage-enabled binary. But don't we
> want to combine the unit tests and integration tests for the coverage report?

I've pushed a small change that combines the two reports.

I don't like this, but for now seems ok to me.

What I would prefer is to do test-driven development. So the unit test coverage should be close to 100%, and the unit coverage report will be just a guide of how well we are doing TDD.
On top of that, I would use the functional tests to cover the happy paths of the user-facing features. Plus some regressions tests or tests for important error conditions. Then the integration coverage report won't be close to 100%, and the simple table is not useful. What's useful is the HTML report that we can use to discover important user-facing features not covered.

There is no correct approach here, so we can discuss and feel free to disagree. If we decide to go the full TDD way, we can split the reports later and display the HTML nicely in the jenkins server.

thanks for the reviews!

96. By Leo Arias

Combine the two coverage reports.

Revision history for this message
Michael Terry (mterry) wrote :

Well, I guess I considered integration tests a part of TDD too. But maybe that's not the Correct way.

You're the testing expert. :) If you would rather see us drive unit tests to 100% separately from integration tests, that's fine and we can split them.

Revision history for this message
Leo Arias (elopio) wrote :

Here's your typical "expert" comment: there's no correct way :)
Lets play with this for now, and try to increase the overall coverage.

Revision history for this message
Michael Vogt (mvo) wrote :

I was assuming we would keep them separate as they are a different kind of testing. But its fine and easy enough to change later so no issue from my side.

Revision history for this message
Leo Arias (elopio) wrote :

approved too soon? sorry about that.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches

to all changes: