[jboss-as7-dev] Keeping testsuite "API" consistent // -DskipTests argument no longer ...
Ondřej Žižka
ozizka at redhat.com
Mon Nov 28 16:27:47 EST 2011
Jaikiran Pai píše v Po 28. 11. 2011 v 15:05 +0530:
> Comments inline.
-"-
> Since these flags apply to the EAP testing, why
> not have a specific script which deals with all these flags and that
> script can then be used for EAP testing?
Well, since the testsuite is maven-based, the script can only use what's
really in pom.xml's.
I could move some steps (e.g. server config) to the script.
But I think that having all in one place is beneficial: If a bug in EAP
is found, then it's easy for the developer to reproduce - they'll simply
use same set of maven properties.
Maybe my words "more and more" scared you a bit :) It's not that bad,
especially after splitting to modules, the pom.xml's are not that hard
to read anymore.
And since we have gone the modularized way, I can keep the functionality
outside of scope of the "normal" build, i.e. not include some modules at
all - only for EAP builds / test runs.
What I mean is:
testsuite
+ integration
+ configure-database
+ configure-ipv6
+ group-smoke
+ group-basic
+ group-iiop
And activate the submodules on demand.
> My point is not about adding
> these new flags but is more about having to expect the non-QA developers
> (for whom those are irrelevant) to understand and use these flags for
> the builds.
Actually, I try not to change the behavior unless someone asks for some
change - that's the case of -DskipTests btw.
I didn't assume anyone relying on that.
And, this was not in testsuite requirements, which we discussed for a
while on this list.
But as I wrote - it's coming back.
>
> > But I can keep you uninformed and keep the testsuite running without
> > changes of "API" if that helps.
> I guess, you meant informed. Yes, that would help - if adding the flags
> helps QA testing but doesn't have any impact on the "API" and helps keep
> the testsuite running, then I have no objection to those changes/flags.
Okay. How about others?
> >> The actual
> >> question for this specific issue is what's the real usecase of skipping
> >> unit tests (which potentially can have failures) but still want to run
> >> the integration tests?
> > Often it happens that some unit tests fail and block one step AS build
> > & testsuite execution.
> So far I haven't seen any unit test fail in AS7 (and if some of them are
> failing then those need to be fixed). Yes, there are integration test
> failures which are intermittent. But those issues need to be fixed. Like
> I said in my earlier reply, building the entire project by using
> -DskipTests (to skip all tests) and then cd testsuite/integration; mvn
> clean install (to run the integration tests) is what you are looking for
> in such cases. Ofcourse it's a 2 step process but to me that's more
> logical (and can even be added to a script) than adding and integrating
> some new property.
Okay. Someone from QA wanted to be able to run in one step due to some
Jenkins issue with Maven-based build, I'll discuss that.
>
> > And let me ask the other way around - what is the use case of
> > -DskipTests, skipping all tests?
> Yes.
That was like a part of the question - what is the use case of skipping
_all_ tests?
* As you said, unit tests should be rock solid and you rarely see a
failure.
* So you skip tests to make the build faster, not because of unit tests
failures.
* So you'd probably like to skip testsuite module to make it even
faster.
Then I don't understand why you dislike the idea of having a separated
flag to skip the testsuite. ?
Ondra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20111128/3a8ac5e7/attachment-0001.html
More information about the jboss-as7-dev
mailing list