B2G/QA/Automation/Style Guide/Python Script Style

Python Script Style Guide

Naming

• Module names should be called test_ and then behavioral areas.

   test_search.py

• Test method names should always show the intent of the test case.

# Good
def test_that_advanced_search_does_not_find_item(self):

# Bad
def test_advanced_search(self):

File Headers

• Each file should have a completed copy of the MPL2 license block, immediately followed by an empty line.
• Each file should pass PEP8 except for line length, see below.

# Good
def method(self, parameter) 

# Bad
def method(self,parameter)

• Lines should try not to have more than 100 characters.
• Docstrings should conform to PEP0257 and should be on a single line wherever possible.

# Good
def click_login():
"""Clicks the login link."""

# Bad
def click_login():
"""
Clicks the login link.
"""

Where not possible, the first line should be a summary.

# Good
def login():
"""Logs in.

Clicks the login link and then waits for the home page to load.

"""

# Bad
def login():
"""Logs in.
Clicks the login link and then waits for the home page to load."""

• 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.
• Comments should be used carefully. Try not to put comments that don't provide any additional value
• Class names should be in Pascal style as this is Python idiomatic.

# Good
class TestThisSite:
    
# Bad
class test_this_site:

Actions

• 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)

• Actions should wait for the appropriate action to complete. This could be an implicit or explicit wait. For example, clicking a login button might explicitly wait for a username field to be visible.

Use testvars.json

TBD - njpark

Using high-level methods

TBD - jlorenzo

• In a test, make sure to only have steps that are high level (for instance: messages.send_an_sms_to_yourself() instead of detailing every single tap and click)

Avoid sleep() calls

TBD - njpark

Variable naming

TBD - jlorenzo

• Name your variables with units. For example: timeout_in_seconds, width_in_pixels
• Don't shorten variable names. A bad example: self.t_out_err_tim = 1000 instead of self.time_out_error_time

app.py and regions/helper.py

TBD - njpark

How to create filename strings

TBD - njpark http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/settings/app.py#296

Meaningful custom Assert() messages

TBD - njpark

https://bugzilla.mozilla.org/show_bug.cgi?id=1198449#c2

Clean up afterwards

TBD - njpark

Avoid code duplication

TBD - jlorenzo

• Use parameterized()
• Centralize workarounds

Simulate end-user check

TBD - jlorenzo

• Check what an end-user would check.
• Make sure manifest.ini is updated with right flags

Making test multi-locale

TBD - njpark

• we check the raw text in order to verify the input from the user (for instance a phone number put in the dialer, we verify it appears in the call log)
• we test the l10n-id for any string that comes from Gaia only (like an error message)

Be aware of outside consumers of ui-test

TBD - mwargers

• Be aware if you change the Gaia UI test API, that outside consumers (mtbf, etc) might get broken