[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.buckminster] Re: Automated Testing of RCP Products with Buckminster

Hi Tas,

Tas Frangoullides schrieb:
Hi Johannes,

I can see how that would work. In your approach do you consider the build broken if the tests fail and do you use the hudson history to reflect this?

In our case the test job gets executed regulary and is a throw-aways product because the class files get instrumented with cobertura and stuff while the other job gets exectuted only manual in case of a release and only if the test job is stable, of course.

Ideally I'd want one build which includes testing so I have only one build to monitor. So far I have created a seperate feature for the all the tests, much like you, but instead I build a sepereate site for it including all the dependecies. That's where I'm up to. The added complexity here (which I'm yet to resolve) is I now need to install both my rcp product and the test plugins to a new location so I can run the tests. I'm hoping this will work and I was thinking I could director to do this. I notcied some code in your ant scripts for the MailApp which can help me do this and was going to try those.

What do you think?


That sounds reasonable to me. It actually shouldn't be much of a problem. Sticking to the mailapp example you could for example have an action similar to the create.product action (create.test.product) that creates the RCP at a different location and uses a different installable unit that contains the test fragments. Or you could use the same IU and simply install the feature containing the test fragments on top of that.
On the test product you may then run your plugin tests and hudson will make sure that the artifacts of the real product are only archived if the build run was stable (which will depend on your unit test results).


If you have any suggestions on how the buckminster plugin for hudson can support your workflow, please let me know.

Btw, unrelated to this topic, but since you're using hudson + buckminster as well:
I'm currently working on a feature for better target platform support in the hudson plugin. My idea was to have a build publisher similar to 'Archive Artifacts' that takes a directory to archive as well as a name under which this target platform will be made available.


In all other jobs that use a buckminster build step you may then select the available target platforms from a drop down box. That will cause the plugin to set the buckminster targetPlatformPath to the archived target platform and also introduces the job that creates the TP as an upstream project. That means: if you build the target platform again, all downstream projects (projects that reference this TP) will be build again.
Sounds useful to you? Any additional ideas for that?


Best regards,
Johannes

Thanks,
Tas


"Johannes Utzig" <mail@xxxxxxxxx> wrote in message news:h56k91$9lc$1@xxxxxxxxxxxxxxxxxxxx
Hi Tas,

what I am doing right now is this:
I have two different jobs in hudson
-one that just builds the RCP with buckminster
-and one that builds the RCP and executes the tests

All tests are in plugin fragments and get aggregated by an all-tests feature.
The RCP that gets build for the test job includes the regular feature(s) + the tests feature and all test dependencies (like the test framework and junit).
Once the buckminster build step is done with creating the RCP I invoke an ant script that executes the plugin tests with the test framework and then hudson can pick up the test results from the workspace.
Works fine for me, but of course it will be more convinient once the buckminster junit support is in place.


Best regards,
Johannes

Tas Frangoullides schrieb:
Hi Achim,

Yeah. I guess this isn't going to be useful to me yet. Great to know it's in the pipeline though.

For now I'm thinking that wrapping the eclipse.test framework with a buckminster action is best way forward, unless anyone has a better idea.

So I'm curious: Are any tests executed during the build for buckminster itself?

Thanks,
Tas

"Achim Demelt" <a.demelt@xxxxxxxxxxxxx> wrote in message news:h56i03$ipq$1@xxxxxxxxxxxxxxxxxxxx
Tas,

I published a very early demo version here: http://buckminster-
contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_17163268.zip



This version is rather old (around the 3.5 RC timeframe), so I cannot
guarantee that it's still working. Also, please read
http://code.google.com/p/buckminster-contrib/wiki/BuckminsterJUnit before
trying it out. The most important restriction is that it's _not_ capable of
running plug-in tests. It only supports plain Java JUnit tests. This will
probably render it pretty much useless for your RCP tests...


Regards,
Achim

Tas Frangoullides wrote:

Hi Achim,

Is there an update site I can get this from to try it out?

Thanks,
Tas


"Achim Demelt" <a.demelt@xxxxxxxxxxxxx> wrote in message news:h56du9$chm$1@xxxxxxxxxxxxxxxxxxxx
Tas,

This is work-in-progress. Please see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
information.

The headless build will then basically be able to run the tests in the
same
way as you would run them interactively in your IDE.


Regards,
Achim

Tas Frangoullides wrote:

Hi,

I wondering what the best way of approaching testing with buckminster
is. I tried examining the buckminster build to find out where you run
your tests but I can't see anything.


My previous builds use the Eclipse Test Framework. They create an
eclipse environment from the recently built distribution artifacts,
install the tests and necessary dependencies and then kick-off the tests
and gather results. I'm not sure where buckminster could be leveraged in
this and was
curious about the new test functionaloty you are adding. Where would
this fit in?


Thanks,
Tas