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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
