Community
Participate
Working Groups
As Tomasz suggested, we could start from testing create/apply patch actions. We may perhaps add Ketan to the cc list.
(In reply to comment #0) > As Tomasz suggested, we could start from testing create/apply patch actions. Yep, the wizard caused us some trouble in the past so it would be a perfect candidate for writing the first test with SWTBot. The next thing could be writing regression tests for navigation (prev/next diff/change) as mentioned in bug 283641, comment 10.
I'm currently the only committer on SWTBot at the moment, and I'm hiring :) Let me know how I may be of any help to help this effort.
Created attachment 143503 [details] UI test with SWTBot v01 The attachment contains an exported project with initial set of simple tests. In the future we could consider adding the tests to an existing test project[1] for compare and submitting patches instead of whole project. Anyway, the first case we wanted to cover was opening the Apply Patch wizard. ApplyPatchTest[2] class shows how we managed to do it. Of course, there is still plenty of space for other cases regarding the wizard we didn't cover, but so far so good. The next step was to test the way navigation works in Compare Editor[3] and this is when we hit first obstacle: trying to click on an item in the context menu showed a problem with selecting right items in the tree: see bug 283219 and bug 261360. This also made us realize that in [2] we didn't actually call "Apply Patch" on a folder but we did it for a project. Other observations so far: - SWTBot provides no source bundles, which makes importing a plug-in project from running platform to workspace - all classes in SWTBot are API, there are no internal packages, which is not bad per se but makes the learning curve even steeper as you need to get familiar with larger number of classes then you might actually need - there is no way to test native dialogs (hit Browse and point to a patch somewhere on your disk). I belive bug 271132 covers it To be continued... [1] org.eclipse.compare.tests [2] org.eclipse.compare.ui.tests.ApplyPatchTest [3] org.eclipse.compare.ui.tests.CompareEditorTest
Created attachment 143504 [details] mylyn/context/zip
Maybe it was not expressed directly.... but Ketan, could you look at the tests and give some feedback on them, please. Some SWTBot issues should have higher severities since they block or limit our tests forcing us to use workarounds.
Right, Ketan if you wish I can open a separate bug for the selection problem described in comment 3 and let you decide whether it's actually a dupe of bug 261360. The same with missing source bundles and "all classes are API" issues, ie if you find them reasonable I can file bugs for them.
Reg context menus: The two issues although not dupes appear to have the same causes. Recursive menus are a big problem across different versions of eclipse and platforms. This is merely an observation from the fact that some of my tests occasionally fail on other platforms, but consistently pass on macosx carbon. I'm considering changing the approach for context menus that involves deprecating some of the menu APIs namely menu('foo').menu('bar') to change it to menu(foo, bar) instead so that swtbot can act a bit more intelligently. Regarding all API being public. Yes this is true that all API is marked public, not all of it needs to be public and I'll file a bug for myself to checkout possibilities of moving some API into internal packages. However this will not affect your tests too much since you'd probably not be using these APIs. I'll add another note with my views on the tests you've written so far.
Forgot to add that SWTBot does not provide separate source bundles, the sources are bundled into the binary jars since the entire package is still a few hundred KB, and I'd prefer to package sources with the binary. For now you'll need to install swtbot both in your target platform(for the tests to work) and your runtime workbench (for the Run-As context menu to work). If you have any ideas on simplifying this I'm open to ideas.
Looking at the tests it seems like they could use some abstractions called page objects. "Within your web app's UI there are areas that your tests interact with. A Page Object simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place." In this particular case one could have an abstraction of a CompareEditor that takes in two files for performing diffs. @Test public void canOpenCompareEditor() throws Exception { new CompareEditor(file1, file2).open(); } Also a lot of the code in the tests seem cruft -- things that are orthogonal to the test, but essential for the test to actually work. Creating and deleting projects, finding files in the workspace etc could be abstracted out as well. I also think this brings out another reason for a dsl Some links that may be useful: * http://code.google.com/p/webdriver/wiki/PageObjects * http://github.com/eclipse/dsl4eclipse/blob/master/com.github.eclipse.dsl4eclipse/src/com/github/eclipse/dsl4eclipse/Workbench.java * http://github.com/eclipse/dsl4eclipse/blob/master/com.github.eclipse.dsl4eclipse.test/src/com/github/eclipse/dsl4eclipse/WorkbenchTest.java
(In reply to comment #7) > The two issues although not dupes appear to have the same causes. I will mark this one as blocked by bug 261360 then. > Regarding all API being public. Yes this is true that all API is marked public, > not all of it needs to be public and I'll file a bug for myself I've already done it for you, see bug 285857. > However this will not affect your tests too much since you'd probably not be using these APIs. Right, this was just an observation, not related to the bug itself.
(In reply to comment #8) > For now you'll need to install swtbot both in your target platform(for the tests > to work) and your runtime workbench (for the Run-As context menu to work). If > you have any ideas on simplifying this I'm open to ideas. Filed bug 285892 where are explained more precisely what I'm missing in the current shape of SWTBot. Let's move the discussion about it there.
Given the number of bugs already planned for 3.6 we will probably not have enough manpower to spend enough time on this one -- removing target milestone.
I think we can stop investigation at this point. I opened Bug 307423 for another approach.
