I'm working on a plugin which editor augments on the existing JDT (Java) editor using aspects.
Now, Eclipse text editors that derive from AbstractTextEditor are
organized in clear components, following an MVC architecture. Those
components are then accessed through precise paths,
e.g. reconciliation. You can find one example of a custom reconciler and
the assumptions it can (and does) use on the behavior of the editor
here.
I'd like to write headless unit tests against those assumptions, that would check that my weaving through aspects has not broken anything along the way. For example, in the case of reconciliation, I would like to open an editor, input some incorrect content (with respect to some reconciliation strategy), wait for a while, and check that Problems are indeed reported.
Note that which problems are reported, or how they would be signaled to
the user in a UI component doesn't concern me : I want
to test that my swapping a SourceViewer for a custom one through aspects
doesn't break editor logic, not my specific reconciliation strategy.
(In fact, I'd probably mock it for that test. Moreover, the UI testing, being presumably not runnable in a headless fashion, is beyond the scope of my question.)
It seems this should be easy to do if the appropriate structures existed. Do they ? Is there any test framework or mocks in sync with Eclipse's architectural assumptions that would let me do what I have in mind ? Those would have to reproduce workflow behavior of the existing Eclipse editor. Surely this would be among Eclipse's own unit tests, right ? ... though I can't seem to find anything of the sort. Any ideas ?
