| Re: [bpel-dev] The lack of junit tests |
Hi,
I recently had exactly the same problem when trying to run the BPEL EMF
model outside of an Eclipse workbench (the EMF model is trying to assert
the workbench has been initialized). This problem (non-Workbench
scenarios) is being addressed in [1], however, it's either too old or
wrong - it didn't work out for me. But I found a fix:
BPELPlugin bpelPlugin = new BPELPlugin();
Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("*",
new BPELResourceFactoryImpl());
ResourceSet resourceSet = new ResourceSetImpl();
URI uri = URI.createFileURI(fileName);
Resource resource = resourceSet.getResource(uri, true);
return (org.eclipse.bpel.model.Process)resource.getContents().get(0);
I found this through immense trying out and googling. :-)
I'm actually working on updating a couple of things like this one on the
website, but because of other BPEL-related work haven't been able to
submit any good patches.
Hope this helps. :)
Bye,
Sebastian.
[1] http://www.eclipse.org/bpel/developers/model.php
Am Dienstag, den 25.03.2008, 18:08 +0300 schrieb Dennis Ushakov:
> Hi!
>
> Long time ago we discussed lack of unit tests and still the situation
> has not changed. I thing now is the time for us to look at our code
> and write some tests - reconciliation is working more or less stable,
> but to be sure and stable we need some tests. Probably we need to
> create some testing-plan?
>
> If I remember right, David had intention to commit some testcases but
> still hasn't. Could anyone provide some details (with examples
> preferably) on how should unit-tests for EMF be written. I've tried to
> test BPELUtils.convertStringToNode but encountered a problem. No
> matter how I create Process with corresponding activities I need to
> have alive BPELResource with the Process. And I need to have access to
> AdapterRegistry. This results in the following exception:
> org.eclipse.core.runtime.AssertionFailedException: assertion failed:
> The application has not been initialized.
> at org.eclipse.core.runtime.Assert.isTrue(Assert.java:109)
> at org.eclipse.core.internal.runtime.InternalPlatform.assertInitialized(InternalPlatform.java:138)
> at org.eclipse.core.internal.runtime.InternalPlatform.getAdapterManager(InternalPlatform.java:159)
> at org.eclipse.core.runtime.Platform.getAdapterManager(Platform.java:593)
> at org.eclipse.bpel.model.adapters.AdapterRegistry.adapt(AdapterRegistry.java:211)
> So as I understand I need to initialize application properly before
> running the test. Any ideas how this should be done?
>
> Thanks,
> Dennis
>
> 2007/10/31, David Black <david.black@xxxxxxxxxxxxx>:
> > Hi Dennis,
> >
> > Thanks for the estimates, it is very useful for us to understand the plan
> > and timescales.
> >
> > In terms of examples, we've just completed a major release of Cape Clear,
> > and one of the big features is a SOA Assembly technology that is configured
> > using a Spring-based XML file, for which we built a graphical editor using
> > GMF. We have PDE junit tests that e.g. create an (assembly) project, open
> > the editor, click on all the items in the palette and drop them onto the
> > canvas, then check that the property section for the element was created
> > correctly and all the attributes are present. There are a few test hooks
> > required to do this kind of thing, but we can still get good coverage. The
> > other thing we've just completed is an EMF/DOM reconciliation mechanism for
> > this editor - this is second time we've done this, the first was for our
> > BPEL editor where the approach taken is very similar to what you are doing
> > for the BPEL Designer i.e. it was specific to the BPEL model. For the new
> > editor, we did a more generic mechanism based on the EMF metadata only
> > (mostly). For the reconciliation we have tests which e.g. create a project,
> > open the file in the editor, add all elements in the graphical view, check
> > the XML generated (and vice versa), save the file, reload it. This gives us
> > pretty good coverage of the reconciliation. I'm currently extending this
> > capability up into wizards and dialogs, things which at first glance may
> > seem difficult to junit test, but again with a few test hooks, become quite
> > easy to test (I'm going to write a piece on this shortly, I'll send on the
> > link when its done). As for actual code examples, the best way to achieve
> > that is for us to contribute something - I hope we can get to that point
> > shortly.
> >
> > thanks
> >
> > David
> >
> > > -----Original Message-----
> > > From: bpel-dev-bounces@xxxxxxxxxxx
> >
> > > [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Dennis Ushakov
> > > Sent: Tuesday, October 30, 2007 9:14 PM
> > > To: BPEL Designer project developer discussions.
> >
> > > Subject: Re: [bpel-dev] The lack of junit tests
> > >
> > > Hi David,
> > >
> > > I completely agree with you at this point. It's very
> > > difficult to continue development when there are no unit
> > > tests and you just can't say whether you're breaking
> > > something with your changes.
> > >
> > > Due to lack of time currently I've continued that bad
> > > practice and haven't written any unit-tests, but I know that
> > > I need to write some and I have time frame in my schedule to
> > > write them a bit later.
> > >
> > > Can you provide some examples of your GUI unit tests?
> > >
> > > Thanks,
> > > Dennis
> > >
> > > 2007/10/30, David Black <david.black@xxxxxxxxxxxxx>:
> > > > Hi Simon,
> > > >
> > > > Thanks for the reply. In any editor (we have two GEF/GMF editors in
> > > > Cape Clear Studio), there is actually a lot of code which is is
> > > > unit-testable independently of the UI. And, as it happens, we have
> > > > many junit tests which also directly test our GUIs. Yes,
> > > TPTP is not
> > > > an option for something like this.
> > > >
> > > > Certainly it seems to me that the first thing we're going
> > > to have to
> > > > do - if we move forward with our plans to adopt this editor - is
> > > > develop and contribute tests. But what concerns me is that
> > > no one else
> > > > appears to be doing so.
> > > >
> > > > -David
> > > >
> > > > > -----Original Message-----
> > > > > From: bpel-dev-bounces@xxxxxxxxxxx
> > > > > [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon D Moser
> > > > > Sent: Tuesday, October 30, 2007 3:29 PM
> > > > > To: BPEL Designer project developer discussions.
> > > > > Cc: bpel-dev@xxxxxxxxxxx; bpel-dev-bounces@xxxxxxxxxxx
> > > > > Subject: Re: [bpel-dev] The lack of junit tests
> > > > >
> > > > > Hi David,
> > > > >
> > > > > you're right - at the current moment the editor is more unstable
> > > > > since the reconciliation work betweem DOM and EMF is
> > > going on. This
> > > > > was announced several weeks ago on this list, and also
> > > the fact that
> > > > > in case you want to get a stable version you should
> > > rather stay on
> > > > > the M3 build.
> > > > > Second, as far as the automated JUnits goes, I agree with you. We
> > > > > should have them, they have been planned for some time,
> > > but as you
> > > > > probably know there is not a very good way of doing automated GUI
> > > > > JUnits as soon as GEF is involved.
> > > > > Even TPTP etc. handles this with ... well ... deficiencies
> > > > > ;-) I agree that for the model reconcilitation we could
> > > get better
> > > > > here. We could automate regular JUnits for that special case -
> > > > > however, limited time and resources have been holding us
> > > back here.
> > > > > Feel free to contribute some test cases if you want - we'd really
> > > > > like to have some!
> > > > >
> > > > > Cheers
> > > > > Simon
> > > > >
> > > > > Simon Moser, M.Eng.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Websphere Integration Mail: IBM Deutschland
> > > > > Entwicklung
> > > > > Developer Development smoser@xxxxxx. GmbH
> > > > >
> > > > > Team Lead BPEL Editor com Vorsitzender des
> > > > >
> > > > > Dept. 4722, Bldg. Phone: Aufsichtsrats:
> > > > > Martin Jetter
> > > > > 71032-01, Room 086 +49-7031-16-43
> > > > > Geschäftsführung: Herbert
> > > > > Websphere Solutions and 04 Kircher
> > > > >
> > > > > Services Fax: Sitz der
> > > > > Gesellschaft:
> > > > > IBM Deutschland +49-7031-16-48 Böblingen
> > > > >
> > > > > Entwicklung GmbH 90 Registergericht:
> > > > > Amtsgericht
> > > > > Schönaicherstr. 220, D – Stuttgart, HRB
> > > > > 243294
> > > > > 71032 Boeblingen
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "David Black"
> > > > >
> > > > > <david.black@cape
> > > > >
> > > > > clear.com>
> > > > > To
> > > > > Sent by: <bpel-dev@xxxxxxxxxxx>
> > > > >
> > > > > bpel-dev-bounces@
> > > > > cc
> > > > > eclipse.org
> > > > >
> > > > >
> > > > > Subject
> > > > > [bpel-dev] The
> > > lack of junit
> > > > > tests
> > > > > 30.10.2007 15:58
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Please respond to
> > > > >
> > > > > "BPEL Designer
> > > > >
> > > > > project developer
> > > > >
> > > > > discussions."
> > > > >
> > > > > <bpel-dev@eclipse
> > > > >
> > > > > .org>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > We're in the process of finalising our plans to adopt and
> > > integrate
> > > > > the BPEL 2.0 editor into our product.
> > > > >
> > > > > One of things which really concerns me is the apparent
> > > total lack of
> > > > > junit tests - unless I'm missing something? I see no test
> > > plugins,
> > > > > nor test code in the functional plugins.
> > > > >
> > > > > I checked out HEAD a few hours ago and I've been playing
> > > around with
> > > > > it.
> > > > > The
> > > > > editor seems incredibly unstable. Right now I cannot save
> > > any BPEL
> > > > > file I create. This may be related to the work around
> > > reconciliation
> > > > > between the EMF models and the XML - I understand that the
> > > > > serialization is done via the XML DOM / SSE (is this
> > > understanding
> > > > > correct?). This is the kind of thing which can and really (IMHO)
> > > > > must be accompanied by junit tests.
> > > > >
> > > > > What is the policy of the BPEL Designer project regarding
> > > automated
> > > > > tests?
> > > > >
> > > > > thanks
> > > > > David Black
> > > > >
> > > > > ---------------------------------------
> > > > > David Black
> > > > > Cape Clear Software
> > > > >
> > > > > office: +353 1 2419952
> > > > > mobile: +353 86 6053426
> > > > > email: david.black@xxxxxxxxxxxxx
> > > > > skype: david.black
> > > > > msn: dblack@xxxxxxxxxxxx
> > > > >
> > > > > No virus found in this outgoing message.
> > > > > Checked by AVG Free Edition.
> > > > > Version: 7.5.503 / Virus Database: 269.15.12/1098 - Release Date:
> > > > > 10/29/2007
> > > > > 9:28 AM
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > bpel-dev mailing list
> > > > > bpel-dev@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/bpel-dev
> > > > >
> > > > > No virus found in this incoming message.
> > > > > Checked by AVG Free Edition.
> > > > > Version: 7.5.503 / Virus Database: 269.15.12/1098 - Release
> > > > > Date: 10/29/2007 9:28 AM
> > > > >
> > > > >
> > > > >
> > > >
> > > > No virus found in this outgoing message.
> > > > Checked by AVG Free Edition.
> > > > Version: 7.5.503 / Virus Database: 269.15.12/1098 - Release Date:
> > > > 10/29/2007
> > > > 9:28 AM
> > > >
> > > >
> > > > _______________________________________________
> > > > bpel-dev mailing list
> > > > bpel-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/bpel-dev
> > > >
> > > _______________________________________________
> > > bpel-dev mailing list
> > > bpel-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/bpel-dev
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.503 / Virus Database: 269.15.12/1098 - Release
> > > Date: 10/29/2007 9:28 AM
> > >
> > >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> >
> > Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: 10/30/2007
> > 6:26 PM
> >
> >
> >
> > _______________________________________________
> > bpel-dev mailing list
> > bpel-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/bpel-dev
> >
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Sebastian Breier <Sebastian.Breier@xxxxxxx>
--
Sebastian Breier <breiersn@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
University of Stuttgart
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil