harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [DRLVM] Integration checks (was building from svn on FC5)
Date Mon, 26 Jun 2006 14:40:52 GMT
Anton Luht wrote:
> As far as I understand Andrey, he suggests to run tests when a piece
> of code is integrated into the code base, by the person who has access
> to the repository (committer). A developer shouldn't test his piece of
> code on any platform, though it'd be good if he did it and reported
> results in the JIRA issue.
> I don't know if running tests for hours is suitable for integration
> check, if so, I can suggest using Eclipse automated tests  (can be
> found in download section for each Eclipse release). Total amount of
> tests is > 10000 . They test Eclipse functionality quite deeply. Note:
> they'll fail without GUI.

IMHO, For integration testing it would be enough to run just one test
that verify that the change is not breaking major use case.

Running Eclipse for Java development is one of the major targets of DRLVM development,
so it would be very convenient to have just *one* Eclipse unit test,
that would model basic Eclipse workflow:
* create project
* inject java code
* compile java code
* (maybe) debug java code: set breakpoints, run the program, inquire variable state, etc.

To make this usable for DRLVM committers, the unit test needs to be readily
available, for example, .jar file committed directly to depends/ or downloadable
from some external source. Its download can be handled in exactly the same
way as other dependencies are downloaded by 'ant fetch-depends'.

As a final result, the committer will be able to run a *single* command,
that will verify that changes in the DRLVM do not break Eclipse use case.

Does this make sense?

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message