support for sbt's Integration phase

[fommil]

We'd really love to see unit test coverage and integration test coverage separately. Can you please let me know how to do this, or add this as a feature?

Great tool! I love being able to specify a minimum coverage level in our CI so builds fail when PRs don't have tests :-)

[RichardBradley]

This seems to have broken lots of stuff. See #29, #30, #31

[RichardBradley]

Are there any tests / documentation for how this feature is supposed to work?
I can't see any integration tests in scoverage-samples. Are there any in there?

[fommil]

@jsuereth and @eed3si9n would be the best people to answer the question of documentation for the integration test phase

[sksamuel]

It wasn't meant to be pushed out yet. I fucked up there.

[RichardBradley]

I don't think we need to revert; I'll fix up and make some PRs

[RichardBradley]

I don't think we need to revert

I'm not sure about this, actually.

It doesn't seem to me like this "ScoverageITest" config works at all.

The key line is:

      inConfig(ScoverageITest)(Defaults.itSettings) ++

But "itSettings" in SBT core uses an "inConfig" call itself, so I don't think this does anything useful.

In particular, I don't think there's a working "scoverage-itest:test" command.

Do you have a test case I can try?

Can I submit a PR which reverts this on master for now?

[sksamuel]

Ok so my aim is to re-write the plugin to use 0.13 (and what will be 1.x) best practice. Hence the big changes. As part of that I was trying to introduce integration config.

Since I've pushed up code I didn't mean to being a donkey, we can just revert it all back to the 0.99.5.1 working plugin state and I'll go back to my little shed and do the re-write in private. Or I can do it on a branch and you're welcome to collaborate.

That will fix all these issues you've got and allow people to use 0.99.8 releases of scoverage.

[RichardBradley]

I don't mind -- it might be safest to revert entirely to 0.99.5.1, but I think the PR at #37 reverts just the broken bits while keeping the refactoring that changed the report generation from a "cleanup" step into its own task.

I can do it on a branch and you're welcome to collaborate.

I think we have already solved a very similar problem (integration tests with coverage) in our SBT config, so I'd be happy to contribute to that. The spec needs to be nailed down a bit first. Our integration test use case seems to be a little different to the version in progress here. See my comments on #36.

We have a working version that doesn't conflict with these changes though, so it's not a problem for us if scoverage introduces a slightly different implementation of integration tests.

[sksamuel]

I'm going to revert it back.

Then my aims are -

• no more <<== madness that, and other 0.12 isms, we had previously.
• support integration testing
• allow multi project report generation

These are required before I release 1.x of this plugin.

On 25 July 2014 11:55, Richard Bradley [email protected] wrote:

I don't mind -- it might be safest to revert entirely to 0.99.5.1, but I
think the PR at #37 #37
reverts just the broken bits while keeping the refactoring that changed the
report generation from a "cleanup" step into its own task.

I can do it on a branch and you're welcome to collaborate.

I think we have already solved a very similar problem (integration tests
with coverage) in our SBT config, so I'd be happy to contribute to that.
The spec needs to be nailed down a bit first. Our integration test use case
seems to be a little different to the version in progress here. See my
comments on #36 #36.

We have a working version that doesn't conflict with these changes though,
so it's not a problem for us if scoverage introduces a slightly different
implementation of integration tests.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[sksamuel]

IT is supported in 1.0.0.Beta2 onwards.