Ok that would be equivalent to run Eclipse in Headless Mode. I am not experienced with that and I have no clue how to stimulate/trigger Editor events in that mode. File Activities are quite easy.
On 16.09.2014 11:07, Lutz Prechelt wrote: > I see my previous email was unclear. > >> I was already able to do some integration tests long time ago. > [...] >> 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. > This is not what I meant. > I meant nearly-complete system tests. > No mocking at all. > Only replacing driving-tests-through-the-GUI with > driving-them-through-a-different-driver (and a more > convenient one). > > What I forgot to mention to make my email more clear is > that this will require some way of calling BULF > operations remotely. > (And this should be enabled only with a 'remote testing' > option turned on because otherwise it would be a huge > security loophole.) > > Lutz > >> 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.clkt >> rk >>> _______________________________________________ >>> 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
