589940 - Page object model prototype for AMO

Status: RESOLVED INVALID

(Testing Graveyard :: WebQA, defect)

Description

[Truman Smith [:truman]]

Attachment: test case - check a sort on add-on browse page

The test case is a prototype that is functional.  It is slightly unfinished in that parameters normally coming from TCparms is hardcoded, and there is no login method available, yet.  But those details won't significantly change the look of a final test case.

In theory, it should be largely self.explanatory.

Comments about overall structure:

Generally, locators don't need to appear in test cases.  They're in the page-specific classes, or the AMO page class for shared elements like the page header or search panel.  A test case gets data with a method that's specific for the element.  Selecting something is done through a method specific for that control.

In principle, the only class containing selenium APIs calls is the base_page class, parent of all other page classes.  This could allow us to add logic around selecting options or opening pages which will be global to all tests cases.

Comment 1

[Truman Smith [:truman]]

Attachment: addon browse page class

Comment 2

[Truman Smith [:truman]]

Attachment: category landing page class (used by browse page class)

Comment 3

[Truman Smith [:truman]]

Attachment: landing page class (used by browse page class)

Comment 4

[Truman Smith [:truman]]

Attachment: amo_page class - elements and actions on all AMO pages

Comment 5

[Truman Smith [:truman]]

Attachment: base_page - parent of all other classes - selenium APIs

Comment 6

[Vishal Kamdar [:vish_moz]]

Comment on attachment 468469 [details]
test case - check a sort on add-on browse page

1. do not use 'from x import y' format. just use import x. we have seen issues with the former format.
2. we are not going to use __init__(self, testName, tc_params = TCparams.localTest()): anymore
3. __init__() function is missing the *_page.py classes
4. your locators are xpath. use CSS if possible.
5. remove all print statements (this has been discussed several times)

Comment 7

[Vishal Kamdar [:vish_moz]]

Comment on attachment 468485 [details]
base_page - parent of all other classes - selenium APIs

we are going to use common page.py for all apps (AMO, SUMO). Your BasePage class is not required. use the page.py class from the sumo svn.
Also, do NOT put  # DATA CONVERSION
 methods in this class. In page.py only functions that can be performed on  a web page will go here.

Comment 8

[Truman Smith [:truman]]

(In reply to comment #7)
> Comment on attachment 468485 [details]
> base_page - parent of all other classes - selenium APIs
> 
> we are going to use common page.py for all apps (AMO, SUMO). Your BasePage
> class is not required. use the page.py class from the sumo svn.
> Also, do NOT put  # DATA CONVERSION
>  methods in this class. In page.py only functions that can be performed on  a
> web page will go here.

Would data conversion methods go into the amo_page class?

Comment 9

[Truman Smith [:truman]]

(In reply to comment #6)
> Comment on attachment 468469 [details]
> test case - check a sort on add-on browse page
> 
> 1. do not use 'from x import y' format. just use import x. we have seen issues
> with the former format.
> 2. we are not going to use __init__(self, testName, tc_params =
> TCparams.localTest()): anymore
> 3. __init__() function is missing the *_page.py classes
> 4. your locators are xpath. use CSS if possible.
> 5. remove all print statements (this has been discussed several times)

What is new interface for #2?

Don't understand #3.

Comment 10

[Vishal Kamdar [:vish_moz]]

(In reply to comment #8)
> (In reply to comment #7)
> > Comment on attachment 468485 [details] [details]
> > base_page - parent of all other classes - selenium APIs
> > 
> > we are going to use common page.py for all apps (AMO, SUMO). Your BasePage
> > class is not required. use the page.py class from the sumo svn.
> > Also, do NOT put  # DATA CONVERSION
> >  methods in this class. In page.py only functions that can be performed on  a
> > web page will go here.
> 
> Would data conversion methods go into the amo_page class?

No. They would have to go in another class, e.g. common_functions.py. Then you can derive your amo_page.py from two classes, page.py & common_functions.py

Comment 11

[Vishal Kamdar [:vish_moz]]

(In reply to comment #9)
> (In reply to comment #6)
> > Comment on attachment 468469 [details] [details]
> > test case - check a sort on add-on browse page
> > 
> > 1. do not use 'from x import y' format. just use import x. we have seen issues
> > with the former format.
> > 2. we are not going to use __init__(self, testName, tc_params =
> > TCparams.localTest()): anymore
> > 3. __init__() function is missing the *_page.py classes
> > 4. your locators are xpath. use CSS if possible.
> > 5. remove all print statements (this has been discussed several times)
> 
> What is new interface for #2?
> 
> Don't understand #3.

For # 2 we don't have anything. SO I guess you have still have to use the same old __init__() in tc's.

# 3 refers to  addon browse page class.

Also in addon browse page class why do you have  
            # On landing page...
            landing_page = AddonLandingPage(self.selenium)
If you want to be consistent with SUMO just pass the new page's object as a parameter.

Comment 12

[Tanay Gavankar [:tgavankar]]

The way tcparams  currently works, I don't think there's a workaround for using __init__. We need to pass tcparams to the TCs somehow, but we also need to make sure the TC inherits all the unittest methods as well.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Not gonna do it; wouldn't be prudent at this juncture (seriously, though, it's invalid with our new setup).

-> invalid