I was already able to do some integration tests long time ago. See http://saros-build.imp.fu-berlin.de/gerrit/#/c/527/
It is still quite painful. What you need to mockup/fake is some Network stuff (which is easy ...) the IEditorManager interface (simulating edit events, although you could just fire them by installing your own Activity Producer) and the SharedResourceManager stuff. But there are still some components that currently are programmed in such a way that they only work in a specific IDE environment. A first good step would to ensure that the whole negotiation procedure could be executed without any IDE present. BR, Stefan On 16.09.2014 09:45, Lutz Prechelt wrote: > Christian, > > if GUI test automation on IntelliJ turns out to be too painful > or the implementation of a DSL for unifying GUI test automation > between Eclipse and IntelliJ turns out to be too painful, > we could use a different approach: > > Perform most of the testing at a level _just_ below the GUI. > That would no longer be system testing but rather integration > testing, with deep integration. > For that we would need a Business Layer Façade (BULF) from > which > - we can trigger everything we would otherwise like > to trigger via the GUI (albeit probably on a coarser grain) > and > - we can query everything we would otherwise > like to query from the GUI. > > The BULF would obviously be part of the Saros Core. > > I wonder how much of the BULF already exists? > > Such testing would not test the GUI as such, but the > BULF would be a much more convenient platform from which > to test all the rest of Saros than the GUIs would be. > No additional DSL would be needed in this case (in fact > the DSL for the GUI case would probably look a lot like > the BULF). > > Introducing the BULF would also trigger much helpful > refactoring, I guess. > > Comments, anybody? > > Lutz > > > > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce. > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
