Merge lp://qastaging/~dpniel/ubuntu-autopilot-tests/gedit into lp://qastaging/ubuntu-autopilot-tests

Ok, I would do a few things here. This testcase looks like we can really test the app so much more with the new introspection bits. Good stuff!

Things we should do before pushing this:

-- Let's try and remove the basic sleeps

1) Remove this by checking for a new tab -- #Why not just check there is eventually a new tab???????
I see this logic in the code that could work
        documents = self.app.select_many('GeditTab')
        #note index starts at 0
        self.assertThat(documents[orginalNumDocuments].name, Contains(str(orginalNumDocuments + 1)))

2) The sleep(3) occurences. They occur waiting for subwindows like open/save/close dialogs. Can we check properly for these to appear? If not, we should think carefully about pushing anyway, if we want this to go to prod.

-- Let's comment out completely the tests that have no asserts, or add a simple assert. Every test needs a assert or there's no reason to even run it.

Things still needing work for later:

-- We should stop using keyboard shortcuts for everything and convert to mouse movements where it makes sense. Click the save button, don't use alt+s, etc

-- We should finish out some of the stubbed testcases; anything we've commented out above, along with expanding the testcases using objects since we can access them now.

On this comment, can't we use an eventually looking at the recent docs label instead?

        #inserted sleep to see the recent files otherwise window closes too quicly
        sleep(2)

Let's just comment these out;
test_highlight_searched_text
test_shortcuts

I think you could uncomment this; even add to it easily
test_insert_overwrite_mode

Comment or implement;
test_tab_manipulation

This could be an easy assert fix; test_display_file_browser_panel

I totally agree,

Looking through the test i can't see an area where sleeps will be required, so i will lose all of them as we can just wait on the visible property to change.

I will work on all those changes tomorrow and take it further as I can see areas that can now be tested. With whats available now to introspect we can definately make a very solid test for gedit.

I did file a bug for higlight test which is possible although we can't see the highlighted text we can introspect the search box and from there when entering a search query if you hit enter twice the word you queried dissapears and then test the textview buffer that it has gone. So as long as before the search we can assert the buffer text then assert the search query box entry was typed correctly and then assert that the word dissapears from the textview buffer we can safely say it highlighted it.

anyway i will re-work it and see how we go :-)

> I did file a bug for higlight test which is possible although we can't see the
> highlighted text we can introspect the search box and from there when entering
> a search query if you hit enter twice the word you queried dissapears and then
> test the textview buffer that it has gone. So as long as before the search we
> can assert the buffer text then assert the search query box entry was typed
> correctly and then assert that the word dissapears from the textview buffer we
> can safely say it highlighted it.

This is really clever! I can see this working!

Ok so now I have expanded this test quite significantly. Running 63 tests lasts like 15 mins atm :-O there is still plenty more tests to be written e.g print preview window and print dialog. We could also do some more save file tests but i think as it stands right now we can push this into production and get some meaningful test output.

just looked further into the print dialog and it seems we can't see as much in that and it will require alot of walking the tree to find the right objects. so will take a while to do and not sure how we can test print preview with zoom etc as there seems to be no visual of zoom level, maybe we can see it in the properties though. There is already test for opening print preview so we know it opens. i will add ones for close using button and esc key and see from there.

Just repeating a bit of the IRC conversation. I'd like to see some focus asserts before typing text if possible, provided there exists such a property in the gedit object. In addition, I would move the command line tests to use a true command line call and skip using terminal. In addition, add --new-document and --new-window as tests.

Overall, this look great and is a new benchmark for gtk tests moving forward. Kudos Dan!

So i have used the is_focus property where ever possible when entering text. I have also seperated the command line tests to load documents not using the terminal. And finally 2 tests for --new-document and --new-window. If you can think of more let me know :-)

Not as many is focus as we could have hoped for. Still, excellent work, let's get this in prod