Bug 299426 - provide tweaklet in o.e.ui.tests to allow e4 compat to run the tests
Summary: provide tweaklet in o.e.ui.tests to allow e4 compat to run the tests
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.6   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 298671
  Show dependency tree
 
Reported: 2010-01-12 15:49 EST by Paul Webster CLA
Modified: 2014-06-26 12:26 EDT (History)
3 users (show)

See Also:


Attachments
api test helper approach v01 (21.68 KB, patch)
2010-01-18 11:13 EST, Paul Webster CLA
no flags Details | Diff
api test facade v01 (23.34 KB, patch)
2010-01-18 13:17 EST, Paul Webster CLA
no flags Details | Diff
Test Facade v03 (22.55 KB, patch)
2010-02-08 12:24 EST, Paul Webster CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Webster CLA 2010-01-12 15:49:54 EST
We will add a tweaklet to 3.6 that will allow us to replace some of the use of internals in our ApiTestSuite.

ex:

WorkbenchPage page = (WorkbenchPage) fPage;

to

WorkbenchPageHelper page = tweaklet.createWorkbenchPage(fPage);

Each helper will provide the method signatures of the original and in 3.6 will simply cast and delegate internally.

In e4, then we can "play".

PW
Comment 1 Paul Webster CLA 2010-01-18 10:44:46 EST
haha ... an interesting corrollary is that the helper must return other helpers for internal classes ... that means no Perspective or IActionSetDescriptor.

PW
Comment 2 Paul Webster CLA 2010-01-18 11:13:15 EST
Created attachment 156399 [details]
api test helper approach v01

This way of fixing the tests involves providing helpers for any internals that the tests need.

Then in 3.x we have delegators and in e4 we will need to cook up some equivalent.

There is another option ... instead of creating object helpers, create test helpers.  Methods on the tweaklet with as many parameters as needed, and do the cast-to-internals/asserts in there.

Then we provide the e4 "equivalent" test/assert in our e4 tweaklet ... this means we can provide equivalent tests, but we have to be careful that our tests amount to the same thing.

Boris, Remy, what do you think we should try.

PW
Comment 3 Paul Webster CLA 2010-01-18 11:28:14 EST
OK, after talking to Remy I'll attach a patch where it is a test helper, not a internal object helper and see how that goes.

Also, we'll have to modify the static that adds the default to use reflection so it doesn't choke in e4.

PW
Comment 4 Paul Webster CLA 2010-01-18 13:17:14 EST
Created attachment 156419 [details]
api test facade v01

This takes the other approach.  Delegate requests for internal information to the test facade.  Allow it to assert conditions if necessary.  The facade methods will only take API.

PW
Comment 5 Paul Webster CLA 2010-01-18 14:39:22 EST
(In reply to comment #4)
> Created an attachment (id=156419) [details]
> api test facade v01

I've released this into o.e.ui.tests HEAD.

I've added another plugin to the e4.compat.psf that provides the e4 tweaklet and updated MANIFEST.MFs so that everybody can see the right classes at runtime.

PW
Comment 6 Paul Webster CLA 2010-02-08 12:24:50 EST
Created attachment 158490 [details]
Test Facade v03

Released to HEAD

PW
Comment 7 Remy Suen CLA 2010-02-08 12:38:31 EST
I've released changes to the e4 tweaklet as they were missing the concrete implementations of the abstract methods.
Comment 8 Paul Webster CLA 2010-02-08 14:45:30 EST
Updated ViewUtil for the StickyView tests.

PW