QA/Execution/Web Testing/Docs/Automation/StyleGuide: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 34: Line 34:
<pre class="brush:py;toolbar:false;">
<pre class="brush:py;toolbar:false;">
     # Good
     # Good
     class TestThisSite(unittest.TestCase):
     class TestThisSite:
      
      
     # Bad
     # Bad
     class test_this_site(unittest.TestCase):
     class test_this_site:
</pre>
</pre>



Revision as of 15:41, 25 May 2011

The goal of the style guide is to try provide rules to write code that looks the same no matter what project. It is a guide and is always up for discussion by the team. I have created templates based on the details below.

All Files

File headers

  • At the top of each file should have python file header
    #!/usr/bin/env python
  • Each file should have a completed copy of the MPL
  • Each file should pass PEP8 except for line length, see below.
    • I.e. parameters should have a comma and a space e.g.
    # Good
    def method(self, parameter) 

    # Bad
    def method(self,parameter)


    • Lines should try not to have more than 100 characters. This allows 2 files to be side by side with no overlap for easier development.(I base this on MacVim on my MBP)
    • Indenting should be a soft tab(4 spaces) as common with in Python. Do not mix tabs and spaces
    • There should be no whitespace at the end of the file(as per PEP8)
    • Comments should be on the line above. Remember to update comments when changing code so that code matches the comments.
    • Class names should be in Pascal style as this is Python idiomatic
    # Good
    class TestThisSite:
    
    # Bad
    class test_this_site:

Page Object Style Guide

  • All Page Objects should inherit from Page in page.py
  • Page Objects should not do asserts. This should be done within the test
  • Each Page should be grouped within one module
  • If using mutliple words to describe a module separate them with underscores '_'
   test_search.py
  • timeout time should be taken from vars.py
  • Locators Class Variables
    • Locator variables should be prefixed with _ to show that it is "private"
    • Variables should be descriptive of the area and not clash with any properties
    • Suffix of _locator
  • Accessing Locator Variables
    • Accessing Locators should be done through a property method as this keeps the locator as readonly.
    @property
    def search_box(self):
        return self.search_box_locator
  • This approach can also be used with get_* calls with Selenium making it more idiomatic for the call.
    @property
    def page_title(self):
        return self.selenium.get_title()
  • Action methods
    • Methods that perform actions on the page should indicate the action in the method name
    # Good
    def click_report_with_length(length)

    # Bad
    def report_length(length)

Test Style Guide

  • Module names should be called test_ and then behavioural areas. E.g. test_search_positive.py
  • Test setup should read in details from conftest.py
  • Test Case names should always show the intent of the test case.
    # Good
    def test_that_advanced_search_doesnt_find_item(self, testsetup):

    # Bad
    def test_advanced_search(self):


  • Tests should handle the asserts not the Page objects