Playwright is an awesome new browser automation library. With Playwright, you can automate web UI interactions for testing or for web scraping with a concise, uniform API in one of four languages: Python, C#, Java, and JavaScript. Playwright is also completely open source and backed by Microsoft. It’s a powerful alternative to Selenium WebDriver.
On December 1, 2021, I delivered a workshop on Playwright for TAU: The Homecoming. In my workshop, I taught how to build a test automation project in Python using Playwright with pytest, Python’s most popular test framework. We automated a test case together for performing a DuckDuckGo web search.
If you missed the workshop, no worries: You can still take the workshop as a self-guided tutorial! The workshop instructions and example code are located in this GitHub repository:
To take the workshop as a self-guided tutorial, read the repository’s README, and then follow the instructions in the Markdown guides under the workshop folder. The workshop has five main parts:
Getting started
What is Playwright?
Our web search test
Test project setup
First steps with Playwright
Browsers, contexts, and pages
Navigating to a web page
Performing a search
Writing assertions
Checking the search field
Checking the result links
Checking the title
Refactoring using page objects
The search page
The result page
Page object fixtures
Nifty Playwright tricks
Testing different browsers
Capturing screenshots and videos
Running tests in parallel
If you get stuck or have any questions, please open issues against the GitHub repository, and I’ll try to help. Happy coding!
Do you want to learn how to automate tests in Python? Python is one of the best languages for test automation because it is easy to learn, concise to write, and powerful to scale. These days, there’s a wealth of great content on Python testing. Here’s a brief reference to help you get started.
If you want to roll up your sleeves, check out Test Automation University. I developed a “trifecta” of Python testing courses for TAU with videos, transcripts, quizzes, and example code. You can take them for FREE!
Have you ever seen those “@” tags on top of Python functions and classes? Those are decorators – functions that wrap around other functions. Confusing? At first, but they’re easy with practice. Useful? Very!
Hello, PyTexas 2020! It’s Pandy Knight here. I’m the Automation Panda, and I’m a big Python fan, just like y’all.
Have you ever seen those “@” tags on top of Python functions? Maybe you’ve seen them on top of methods and classes, too. Those are decorators, one of Python’s niftiest language features. Decorators are essentially wrappers – they wrap additional code around existing definitions. When used right, they can clean up your code better than OxiClean! Let’s learn how to use them.
[Slide]
So, here’s a regular old “hello world” function. When we run it, …
[Slide]
…It prints “Hello World!” Nothing fancy here.
[Slide]
Now, let’s take that function…
[Slide]
…And BAM! Add a decorator. Using this “@” sign, we just added a decorator named “tracer” to “hello_world”. So, what is this decorator?
[Slide]
“Tracer” is just another function. But, it’s special because it takes in another function as an argument!
[Slide]
Since “tracer” decorates “hello_world”, the “hello_world” function is passed into “tracer” as an argument. Wow!
So, what’s inside “tracer”?
[Slide]
This decorator has an inner function named “wrapper”. Can you even do that? With Python, yes, you can! The “wrapper” function prints “Entering”, calls the function originally passed into the decorator, and then prints “Exiting”.
[Slide]
When “tracer” decorates “hello_world”, that means “hello_world” will be wrapped by “Entering” and “Exiting” print statements.
[Slides]
Finally, the decorator returns the new “wrapper” function. Any time the decorated function is called, it will effectively be replaced by this new wrapper function.
[Slides]
So, when we call “hello_world”, the trace statements are now printed, too. Wow! That’s amazing. That’s how decorators work.
[Slide] Decorators [Slide] wrap [Slide] functions [Slide] around [Slide] functions!
[Slide]
Think about them like candy bars. The decorator is like the foil wrapper, and the decorated function is like the chocolate inside.
[Slide]
But how is this even possible? That decorator code looks confusing!
[Slide]
Decorators are possible because, in Python, functions are objects. In fancy language, we say functions are “first-order” values. Since functions are just objects, …
[Slide]
…We can pass them into other functions as arguments, …
[Slide]
…define new functions inside existing functions, …
[Slide]
…and return a function from a function.
[Slide]
This is all part of a paradigm called “Functional Programming.” Python supports functional programming because functions can be treated like objects. That’s awesome!
[Slide]
So, using functions as objects, decorators change how functions are called.
[Slide]
Decorators create an “outer” decorator function around an “inner” decorated function. Remember, the outer function is like the foil wrapper, and the inner function is like the chocolate.
[Slide]
Creating an outer function lets you add new code around the inner function. Some people call this “advice.” You can add advice before or after the inner function. You could even skip the inner function!
[Slide]
The best part is, decorators can be applied to any function. They make sharing code easy so you don’t repeat yourself!
[Slide]
Decorators are reminiscent of a paradigm called “Aspect-Oriented Programming,” in which code can be cleverly inserted before and after points of execution. Neat!
[Slide]
So remember, decorators wrap functions around functions, like candy bars!
[Slide]
Hold on, now! We have a problem in that Python code!
[Slide]
If the “wrapper” function effectively replaces “hello_world”, then what identity does “hello_world” report?
[Slide]
Its name is “wrapper”…
[Slide]
And its help is also “wrapper”! That’s not right!
[Slide]
Never fear! There’s an easy solution. The “functools” module provides a decorator named “wraps”. Put “functools.wraps” on the “wrapper” function and pass in the inner function object, and decorated functions once again show the right identity. That’s awesome.
[Slide]
But wait, there’s another problem!
[Slide]
How do decorators work with inputs and outputs? What if we decorate a function with parameters and a return value?
[Slide]
If we try to use the current “tracer”, …
[Slide]
…We get an error! Arguments broke it!
[Slide]
We can fix it! First, add “star args” and “star-star k-w-args” to the “wrapper” function’s parameters, and then pass them through to the inner function. This will make sure all arguments go through the decorator into the decorated function.
[Slide]
Then, capture the inner function’s return value and return it from the “wrapper” function. This makes sure return values also pass through. If the inner function has no return value, don’t worry – the decorator will pass through a “None” value.
[Slide]
When we call the function with the updated “tracer”, …
[Slide]
…we see tracing is now successful again!
[Slide]
When we check the return value, …
[Slide]
…it’s exactly what we expect. It works!
[Slide]
Wow, that’s awesome!
[Slide]
But wait, there’s more!
[Slide]
You can write a decorator to call a function twice!
[Slide]
Start with the decorator template…
[Slide]
…and call the inner function twice! Return the final return value for continuity.
[Slide]
BAM! It works!
[Slide]
But wait, there’s more!
[Slide]
You can write a timer decorator!
[Slide]
Start with the template, …
[Slide]
…call the inner function, …
[Slide]
…and surround it with timestamps using the “time” module!
[Slide]
BAM! Now you can time any function!
[Slide]
But wait, there’s more!
[Slide]
You can also add more than one decorator to a function! This is called “nesting”. Order matters. Decorators are executed in order of closeness to the inner function. So, in this case, …
[Slide]
…”call_twice” is applied first, and then “timer” is applied.
[Slide]
If these decorators are reversed, …
[Slide]
…then each inner function call is timed. Cool!
[Slide]
But wait, there’s more!
[Slide]
You can scrub and validate function arguments! Check out these two simple math functions.
[Slide]
Create a decorator to scrub and validate inputs as integers.
[Slide]
Add the wrapper function, and make sure it has positional args.
[Slide]
Then, cast all args as ints before passing them into the inner function.
[Slide]
Now, when calling those math functions, all numbers are integers! Using non-numeric inputs also raises a ValueError!
[Slide]
But wait, there’s more!
[Slide]
You can create decorators with parameters! Here’s a decorator that will repeat a function 5 times.
[Slide]
The “repeat” function is a little different. Instead of taking in the inner function object, it takes in the parameter, which is the number of times to repeat the inner function.
[Slide]
Inside, there’s a “repeat_decorator” function that has a parameter for the inner function. The “repeat” function returns the “repeat_decorator” function.
[Slide]
Inside “repeat_decorator” is the “wrapper” function. It uses “functools.wraps” and passes through all arguments. “repeat_decorator” returns “wrapper”.
[Slide]
Finally, “wrapper” contains the logic for calling the inner function multiple times, according to the “repeat” decorator’s parameter value.
[Slide]
Now, “hello_world” runs 5 times. Nifty!
[Slide]
But wait, there’s more!
[Slide]
Decorators can be used to save state! Here’s a decorator that will count the number of times a function is called.
[Slide]
“count_calls” has the standard decorator structure.
[Slide]
Outside the wrapper, a “count” attribute is initialized to 0. This attribute is added to the wrapper function object.
[Slide]
Inside the wrapper, the count is incremented before calling the inner function. The “count” value will persist across multiple calls.
[Slide]
Initially, the “hello_world” count value is 0.
[Slide]
After two calls, the count value goes up! Awesome!
[Slide]
But wait, there’s more!
[Slide]
Decorators can be used in classes! Here, the “timer” decorator is applied to this “hello” method.
[Slider]
As long as parameters and return values are set up correctly, decorators can be applied equally to functions and methods.
[Slide]
Decorators can also be applied directly to classes!
[Slide]
When a decorator is applied to a class, it wraps the constructor.
[Slide]
Note that it does not wrap each method in the class.
[Slide]
Since decorators can wrap classes and methods in addition to functions, it would technically be more correct to say that decorators wrap callables around callables!
[Slide]
So all that’s great, but can decorators be tested? Good code must arguably be testable code. Well, today’s your lucky day, because yes, you can test decorators!
[Slide]
Testing decorators can be a challenge. We should always try to test the code we write, but decorators can be tricky. Here’s some advice:
[Slide]
First, separate tests for decorator functions from decorated functions. For decorator functions, focus on intended outcomes. Try to focus on the “wrapper” instead of the “inner” function. Remember, decorators can be applied to any callable, so cover the parts that make decorators unique. Decorated functions should have their own separate unit tests.
[Slide]
Second, apply decorators to “fake” functions used only for testing. These functions can be simple or mocked. That way, unit tests won’t have dependencies on existing functions that could change. Tests will also be simpler if they use slimmed-down decorated functions.
[Slide]
Third, make sure decorators have test coverage for every possible way it could be used. Cover decorator parameters, decorated function arguments, and return values. Make sure the “name” and “help” are correct. Check any side effects like saved state. Try it on methods and classes as well as functions. With decorators, most failures happen due to overlooked edge cases.
[Slide]
Let’s look at a few short decorator tests. We’ll use the “count_calls” decorator from earlier.
There are two decorated functions to use for testing. The first one is a “no operation” function that does nothing. It has no parameters or returns. The second one is a function that takes in one argument and returns it. Both are very simple, but they represent two equivalences classes of decoratable functions.
[Slide]
The test cases will verify outcomes of using the decorator. For “count_calls”, that means tests will focus on the “count” attribute added to decorated functions.
The first test case verifies that the initial count value for any function is zero.
[Slide]
The second test calls a function three times and verifies that count is three.
[Slide]
The third test exercises the “same” function to make sure arguments and return values work correctly. It calls the “same” function, asserts the return value, and asserts the count value.
This collection of tests is by no means complete. It simply shows how to start writing tests for decorators. It also shows that you don’t need to overthink unit tests for decorators. Simple is better than complex!
[Slide]
Up to this point, we’ve covered how to write your own decorators. However, Python has several decorators available in the language and in various modules that you can use, absolutely free!
[Slide]
Decorators like “classmethod”, “staticmethod”, and “property” can apply to methods in a class. Frameworks like Flask and pytest have even more decorators. Let’s take a closer look.
[Slide]
Let’s start by comparing the “classmethod” and “staticmethod” decorators. We’ll revisit the “Greeter” class we saw before.
[Slide]
The “classmethod” decorator will turn any method into a “class” method instead of an “instance” method. That means this “hello” method here can be called directly from the class itself instead of from an object of the class. This decorator will pass a reference to the class into the method so the method has some context of the class. Here, the reference is named “c-l-s”, and the method uses it to get the class’s name. The method can be called using “Greeter.hello”. Wow!
[Slide]
The “staticmethod” decorator works almost the same as the “classmethod” decorator, except that it does not pass a reference to the class into the method.
[Slide]
Notice how the method parameters are empty – no “class” and no “self”. Methods are still called from the class, like here with “Greeter.goodbye”. You could say that “staticmethod” is just a simpler version of “classmethod”.
[Slide]
Next, let’s take a look at the “property” decorator. To show how to use it, we’ll create a class called “Accumulator” to keep count of a tally.
[Slide]
Accumulator’s “init” method initializes a “count” attribute to 0.
[Slide]
An “add” method adds an amount to the count. So far, nothing unusual.
[Slide]
Now, let’s add a property. This “count” method has the “property” decorator on it. This means that “count” will be callable as an attribute instead of a method, meaning that it won’t need parentheses. It is effectively a “getter”. The calls to “count” in the “init” and “add” methods will actually call this property instead of a raw variable.
Inside the “count” property, the method returns an attribute named “underscore-count”. The underscore means that this variable should be private. However, this class hasn’t set that variable yet.
[Slide]
That variable is set in the “setter” method. Setters are optional for properties. Here, the setter validates that the value to set is not negative. If the value is good, then it sets “underscore-count”. If the value is negative, then it raises a ValueError.
“underscore-count” is handled internally, while “count” is handled publicly as the property. The getter and setter controls added by the “property” decorator let you control how the property is handled. In this class, the setter protects the property against bad values!
[Slide]
So, let’s use this class. When an Accumulator object is constructed, its initial count is 0.
[Slide]
After adding an amount to the object, its count goes up.
[Slide]
Its count can be directly set to non-negative values. Attempting to set the count directly to a negative value raises an exception, as expected. Protection like that is great!
[Slide]
Python packages also frequently contain decorators. For example, Flask is a very popular Web “micro-framework” that enables you to write Web APIs with very little Python code.
[Slide]
Here’s an example “Hello World” Flask app taken directly from the Flask docs online. It imports the “flask” module, creates the app, and defines a single endpoint at the root path that returns the string, “Hello, World!” Flask’s “app.route” decorator can turn any function into a Web API endpoint. That’s awesome!
[Slide]
Another popular Python package with decorators is pytest, Python’s most popular test framework.
[Slide]
One of pytest’s best features is the ability to parametrize test functions to run for multiple input combinations. Test parameters empower data driven testing for wider test coverage!
[Slide]
To show how this works, we’ll use a simple test for basic arithmetic: “test addition”. It asserts that a plus b equals c.
[Slide]
The values for a, b, and c must come from a list of tuples. For example, 1 plus 2 equals 3, and so forth.
[Slide]
The “pytest.mark.parametrize” decorator connects the list of test values to the test function. It runs the test once for each tuple in the list, and it injects the tuple values into the test case as function arguments. This test case would run four times. Test parameters are a great way to rerun test logic without repeating test code.
[Slide]
So, act now, before it’s too late!
[Slide]
When should you use decorators in your Python code?
[Slide]
Use decorators for aspects.
[Slide]
An aspect is a special cross-cutting concern. They are things that happen in many parts of the code, and they frequently require repetitive calls.
Think about something like logging. If you want to add logging statements to different parts of the code, then you need to write multiple logging calls in all those places. Logging itself is one concern, but it cross-cuts the whole code base. One solution for logging could be to use decorators, much like we saw earlier with the “tracer” decorator.
[Slide]
Good use cases for decorators include logging, profiling, input validation, retries, and registries. These are things that typically require lots of extra calls inserted in duplicative ways. Ask yourself this:
[Slide]
Should the code wrap something else? If yes, then you have a good candidate for a decorator.
[Slide]
However, decorators aren’t good for all circumstances. You should avoid decorators for “main” behaviors, because those should probably be put directly in the body of the decorated function. Avoid logic that’s complicated or has heavy conditionals, too, because simple is better than complex. You should also try to avoid completely side-stepping the decorated function – that could confuse people!
[Slide]
Ask yourself this: is the code you want to write the wrapper or the candy bar itself? Wrappers make good decorators, but candy bars do not.
[Slide]
I hope you’ve found this infomercial about decorators useful! If you want to learn more, …
[Slide]
…check out this Real Python tutorial by Geir Arne Hjelle named “Primer on Python Decorators”. It covers everything I showed here, plus more.
[Slide]
Thank you very much for listening! Again, my name is Pandy Knight – the Automation Panda and a bona fide Pythonista. Please read my blog at AutomationPanda.com, and follow me on Twitter @AutomationPanda. I’d love to hear what y’all end up doing with decorators!
TestProject recently released its new OpenSDK, and one of its major features is the inclusion of Python testing support! Since I love using Python for test automation, I couldn’t wait to give it a try. This article is my crash-course tutorial on writing Web UI tests in Python with TestProject.
What is TestProject?
TestProject is a free end-to-end test automation platform for Web, mobile, and API tests. It provides a cloud-based way to teams to build, run, share, and analyze tests. Manual testers can visually build tests for desktop or mobile sites using TestProject’s in-browser recorder and test builder. Automation engineers can use TestProject’s SDKs in Java, C#, and now Python for developing coded test automation solutions, and they can use packages already developed by others in the community through TestProject’s add-ons. Whether manual or automated, TestProject displays all test results in a sleek reporting dashboard with helpful analytics. And all of these features are legitimately free – there’s no tiered model or service plan.
Recently, TestProject announced the official release of its new OpenSDK. This new SDK (“software development kit”) provides a simple, unified interface for running tests with TestProject across multiple platforms and languages (now including Python). Things look exciting for the future of TestProject!
What’s My Interest?
It’s no secret that I love testing with Python. When I heard that TestProject added Python support, I knew I had to give it a try. I never used TestProject before, but I was interested to learn what it could do. Specifically, I wanted to see the value it could bring to reporting automated tests. In the Python space, test automation is slick, but reporting can be rough since frameworks like pytest and unittest are command-line-focused. I also wanted to see if TestProject’s SDK would genuinely help me automate tests or if it would get it my way. Furthermore, I know some great people in the TestProject community, so I figured it was time to jump in myself!
The Python SDK
TestProject’s Python SDK is an open-source project. It was originally developed by Bas Dijkstra, with the support of the TestProject team, and its code is hosted on GitHub. The Python SDK supports Selenium for Web UI automation (which will be the focus for this tutorial) and Appium for Android and iOS UI automation as well!
Since I’d never used TestProject before, let alone this new Python SDK, I wanted to review the code to see how to use it. Thankfully, the README included lots of helpful information and example code. When I looked at the code for TestProject’s BaseDriver, I discovered that it simply extend’s Selenium WebDriver’s RemoteDriver class. That means all the TestProject WebDrivers use exactly the same API as Python’s Selenium WebDriver implementation. To me, that was a big relief. I know WebDriver’s API very well, so I wouldn’t need to learn anything different in order to use TestProject. It also means that any test automation project can be easily retrofitted to use TestProject’s SDKs – they just need to swap in a new WebDriver object!
Setup Steps
TestProject has a straightforward architecture. Users sign up for free TestProject accounts online. Then, they set up their own machines for running tests. Each testing machine must have the TestProject agent installed and linked to a user’s account. When tests run, agents automatically push results to the TestProject cloud. Users can then log into the TestProject portal to view and analyze results. They can invite team mates to share results, and they can also set up multiple test machines with agents. Users can even integrate TestProject with other tools like Jenkins, qTest, and Sauce Labs. The TestProject docs, especially the ecosystem diagram, explain everything in more detail.
When I did my test drive, I created a TestProject account, installed the agent on my Mac, and ran Python Web UI tests from my Mac. I already had the latest version of Python installed (Python 3.8 at the time of writing this article). I also already had my target browsers installed: Google Chrome and Mozilla Firefox.
Below are the precise steps I followed to set up TestProject:
1. Sign up for an account
TestProject accounts are “free forever.” Use this signup link.
The TestProject signup page
2. Download the TestProject Agent
The signup wizard should direct you to download the TestProject agent. If not, you can always download it from the TestProject dashboard. Be warned, the download package is pretty large – the macOS package was 345 MB. Alternatively, you can fetch the agent as a container image from Docker Hub.
The TestProject agent download page
The TestProject agent contains all the stuff needed to run tests and upload results to the TestProject app in the cloud. You don’t need to install WebDriver executables like ChromeDriver or geckodriver. Once the agent is downloaded, install it on the machine and register the agent with your account. For me, registration happened automatically.
This is what the TestProject agent looks like when running on macOS. You can also close this window to let it run in the background.
3. Find your developer token
You’ll need to use your developer token to connect your automated tests to your account in the TestProject app. The signup wizard should reveal it to you, but you can always find it (and also reset it) on the Integrations page.
The Integrations page. Check here for your developer token. No, you can’t use mine.
4. Install the Python SDK
TestProject’s Python SDK is distributed as a package through PyPI. To install it, simply run pip install testproject-python-sdk at the command line. This package will also install dependencies like selenium and requests.
A Classic Web UI Test
After setting up my Mac to use TestProject, it was time to write some Web UI tests in Python! Since I discovered that TestProject’s WebDriver objects could easily retrofit any existing test automation project, I thought, “What if I try to run my PyCon 2020 tutorial project with TestProject?” For PyCon 2020, I gave an online tutorial about building a Web UI test automation project in Python from the ground up using pytest and Selenium WebDriver. The tutorial includes one test case: a DuckDuckGo web search and verification. I thought it would be easy to integrate with TestProject since I already had the code. Thankfully, it was!
The test case covers a simple DuckDuckGo web search. Whenever I automate tests, I always write out the steps in plain language. Good tests follow the Arrange-Act-Assert pattern, and I like to use Gherkin’sGiven-When-Then phrasing. Here’s the test case:
Scenario: Basic DuckDuckGo Web Search
Given the DuckDuckGo home page is displayed
When the user searches for "panda"
Then the search result query is "panda"
And the search result links pertain to "panda"
And the search result title contains "panda"
2. Specify automation inputs
Inputs configure how automated tests run. They can be passed into a test automation solution using configuration files. Testers can then easily change input values in the config file without changing code. Automation should read config files once at the start of testing and inject necessary inputs into every test case.
In Python, I like to use JSON for config files. JSON data is simple and hierarchical, and Python includes a module in its standard library named json that can parse a JSON file into a Python dictionary in one line. I also like to put config files either in the project root directory or in the tests directory.
implicit_wait is the implicit waiting timeout for the WebDriver instance
testproject_projectname is the project name to use for this test suite in the TestProject app
testproject_token is the developer token
3. Read automation inputs
Automation code should read inputs one time before any tests run and then inject inputs into appropriate tests. pytest fixtures make this easy to do.
I created a fixture named config in the tests/conftest.py module to read config.json:
import json
import pytest
@pytest.fixture
def config(scope='session'):
# Read the file
with open('config.json') as config_file:
config = json.load(config_file)
# Assert values are acceptable
assert config['browser'] in ['Firefox', 'Chrome', 'Headless Chrome']
assert isinstance(config['implicit_wait'], int)
assert config['implicit_wait'] > 0
assert config['testproject_projectname'] != ""
assert config['testproject_token'] != ""
# Return config so it can be used
return config
Setting the fixture’s scope to “session” means that it will run only one time for the whole test suite. The fixture reads the JSON config file, parses its text into a Python dictionary, and performs basic input validation. Note that Firefox, Chrome, and Headless Chrome will be supported browsers.
4. Set up WebDriver
Each Web UI test should have its own WebDriver instance so that it remains independent from other tests. Once again, pytest fixtures make setup easy.
The browser fixture in tests/conftest.py initialize the appropriate TestProject WebDriver type based on inputs returned by the config fixture:
from selenium.webdriver import ChromeOptions
from src.testproject.sdk.drivers import webdriver
@pytest.fixture
def browser(config):
# Initialize shared arguments
kwargs = {
'projectname': config['testproject_projectname'],
'token': config['testproject_token']
}
# Initialize the TestProject WebDriver instance
if config['browser'] == 'Firefox':
b = webdriver.Firefox(**kwargs)
elif config['browser'] == 'Chrome':
b = webdriver.Chrome(**kwargs)
elif config['browser'] == 'Headless Chrome':
opts = ChromeOptions()
opts.add_argument('headless')
b = webdriver.Chrome(chrome_options=opts, **kwargs)
else:
raise Exception(f'Browser "{config["browser"]}" is not supported')
# Make its calls wait for elements to appear
b.implicitly_wait(config['implicit_wait'])
# Return the WebDriver instance for the setup
yield b
# Quit the WebDriver instance for the cleanup
b.quit()
This was the only section of code I needed to change to make my PyCon 2020 tutorial project work with TestProject. I had to change the WebDriver invocations to use the TestProject classes. I also had to add arguments for the project name and developer token, which come from the config file. (Note: you may alternatively set the developer token as an environment variable.)
5. Create page objects
Automated tests could make direct calls to the WebDriver interface to interact with the browser, but WebDriver calls are typically low-level and wordy. The Page Object Model is a much better design pattern. Page object classes encapsulate WebDriver gorp so that tests can call simpler, more readable methods.
The DuckDuckGo search test interacts with two pages: the search page and the result page. The pages package contains a module for each page. Here’s pages/search.py:
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
class DuckDuckGoSearchPage:
URL = 'https://www.duckduckgo.com'
SEARCH_INPUT = (By.ID, 'search_form_input_homepage')
def __init__(self, browser):
self.browser = browser
def load(self):
self.browser.get(self.URL)
def search(self, phrase):
search_input = self.browser.find_element(*self.SEARCH_INPUT)
search_input.send_keys(phrase + Keys.RETURN)
And here’s pages/result.py:
from selenium.webdriver.common.by import By
class DuckDuckGoResultPage:
RESULT_LINKS = (By.CSS_SELECTOR, 'a.result__a')
SEARCH_INPUT = (By.ID, 'search_form_input')
def __init__(self, browser):
self.browser = browser
def result_link_titles(self):
links = self.browser.find_elements(*self.RESULT_LINKS)
titles = [link.text for link in links]
return titles
def search_input_value(self):
search_input = self.browser.find_element(*self.SEARCH_INPUT)
value = search_input.get_attribute('value')
return value
def title(self):
return self.browser.title
Notice that this code uses the “regular” WebDriver interface because TestProject’s WebDriver classes extend the Selenium WebDriver classes.
To make setup easier, I added fixtures to tests/conftest.py to construct each page object, too. They call the browser fixture and inject the WebDriver instance into each page object:
from pages.result import DuckDuckGoResultPage
from pages.search import DuckDuckGoSearchPage
@pytest.fixture
def search_page(browser):
return DuckDuckGoSearchPage(browser)
@pytest.fixture
def result_page(browser):
return DuckDuckGoResultPage(browser)
6. Automate the test case
All the automation plumbing is finally in place. Here’s the test case in tests/traditional/test_duckduckgo.py:
import pytest
@pytest.mark.parametrize('phrase', ['panda', 'python', 'polar bear'])
def test_basic_duckduckgo_search(search_page, result_page, phrase):
# Given the DuckDuckGo home page is displayed
search_page.load()
# When the user searches for the phrase
search_page.search(phrase)
# Then the search result query is the phrase
assert phrase == result_page.search_input_value()
# And the search result links pertain to the phrase
titles = result_page.result_link_titles()
matches = [t for t in titles if phrase.lower() in t.lower()]
assert len(matches) > 0
# And the search result title contains the phrase
assert phrase in result_page.title()
I parametrized the test to run it for three different phrases. The test function does not interact with the WebDriver instance directly. Instead, it interacts exclusively with the page objects.
7. Run the tests
The tests run like any other pytest tests: python -m pytest at the command line. If everything is set up correctly, then the tests will run successfully and upload results to the TestProject app.
In the TestProject dashboard, the Reports tab shows all the test you have run. It also shows the different test projects you have.
Check out those results!
You can also drill into results for individual test case runs. TestProject automatically records the browser type, timestamps, pass-or-fail results, and every WebDriver call. You can also download PDF reports!
Results for an individual test
What if … BDD?
I was delighted to see how easily I could run a traditional pytest suite using TestProject. Then, I thought to myself, “What if I could use a BDD test framework?” I personally love Behavior-Driven Development, and Python has multiple BDD test frameworks. There is no reason why a BDD test framework wouldn’t work with TestProject!
So, I rewrote the DuckDuckGo search test as a feature file with step definitions using pytest-bdd. The BDD-style test uses the same fixtures and page objects as the traditional test.
Here’s the Gherkin scenario in tests/bdd/features/duckduckgo.feature:
Feature: DuckDuckGo
As a Web surfer,
I want to search for websites using plain-language phrases,
So that I can learn more about the world around me.
Scenario Outline: Basic DuckDuckGo Web Search
Given the DuckDuckGo home page is displayed
When the user searches for "<phrase>"
Then the search result query is "<phrase>"
And the search result links pertain to "<phrase>"
And the search result title contains "<phrase>"
Examples:
| phrase |
| panda |
| python |
| polar bear |
And here’s the step definition module in tests/bdd/step_defs/test_duckduckgo_bdd.py:
from pytest_bdd import scenarios, given, when, then, parsers
from selenium.webdriver.common.keys import Keys
scenarios('../features/duckduckgo.feature')
@given('the DuckDuckGo home page is displayed')
def load_duckduckgo(search_page):
search_page.load()
@when(parsers.parse('the user searches for "{phrase}"'))
@when('the user searches for "<phrase>"')
def search_phrase(search_page, phrase):
search_page.search(phrase)
@then(parsers.parse('the search result query is "{phrase}"'))
@then('the search result query is "<phrase>"')
def check_search_result_query(result_page, phrase):
assert phrase == result_page.search_input_value()
@then(parsers.parse('the search result links pertain to "{phrase}"'))
@then('the search result links pertain to "<phrase>"')
def check_search_result_links(result_page, phrase):
titles = result_page.result_link_titles()
matches = [t for t in titles if phrase.lower() in t.lower()]
assert len(matches) > 0
@then(parsers.parse('the search result title contains "{phrase}"'))
@then('the search result title contains "<phrase>"')
def check_search_result_title(result_page, phrase):
assert phrase in result_page.title()
There’s one more nifty trick I added with pytest-bdd. I added a hook to report each Gherkin step to TestProject with a screenshot! That way, testers can trace each test case step more easily in the TestProject reports. Capturing screenshots also greatly assists test triage when failures arise. This hook is located in tests/conftest.py:
Since pytest-bdd is just a pytest plugin, its tests run using the same python -m pytest command. TestProject will group these test results into the same project as before, but it will separate the traditional tests from the BDD tests by name. Here’s what the Gherkin steps with screenshots look like:
Custom Gherkin step with screenshot reported in the TestProject app
This is Awesome!
As its name denotes, TestProject is a great platform for handling project-level concerns for testing work: reporting, integrations, and fast feedback. Adding TestProject to an existing automation solution feels seamless, and its sleek user experience gives me what I need as a tester without getting in my way. The one word that keeps coming to mind is “simple” – TestProject simplifies setup and sharing. Its design takes to heart the renowned Python adage, “Simple is better than complex.” As such, TestProject’s new Python SDK is a welcome addition to the Python testing ecosystem.
I look forward to exploring Python support for mobile testing with Appium soon. I also look forward to seeing all the new Python add-ons the community will develop.
A test is a procedure that exercises a behavior to determine if the behavior functions correctly. There are several different kinds of tests, like unit tests, integration tests, or end-to-end tests, but all functional tests do the same basic thing: they try something and report PASS or FAIL.
Testing provides an empirical feedback loop for development. That’s how testing keeps us safe. With tests, we know when things break. Without tests, coding can be dangerous. We don’t want to deploy big ol’ bugs!
So, if we intend to spend time writing tests, how can we write good tests? There’s a simple but powerful pattern I like to follow: Arrange-Act-Assert.
The Pattern
Arrange-Act-Assert is a great way to structure test cases. It prescribes an order of operations:
Arrangeinputs and targets. Arrange steps should set up the test case. Does the test require any objects or special settings? Does it need to prep a database? Does it need to log into a web app? Handle all of these operations at the start of the test.
Acton the target behavior. Act steps should cover the main thing to be tested. This could be calling a function or method, calling a REST API, or interacting with a web page. Keep actions focused on the target behavior.
Assertexpected outcomes. Act steps should elicit some sort of response. Assert steps verify the goodness or badness of that response. Sometimes, assertions are as simple as checking numeric or string values. Other times, they may require checking multiple facets of a system. Assertions will ultimately determine if the test passes or fails.
Behavior-Driven Development follows the Arrange-Act-Assert pattern by another name: Given-When-Then. The Gherkin language uses Given-When-Then steps to specify behaviors in scenarios. Given-When-Then is essentially the same formula as Arrange-Act-Assert.
Every major programming language has at least one test framework. Frameworks like JUnit, NUnit, Cucumber, and (my favorite) pytest enable you, as the programmer, to automate tests, execute suites, and report results. However, the framework itself doesn’t make a test case “good” or “bad.” You, as the tester, must know how to write good tests!
Let’s look at how to apply the Arrange-Act-Assert pattern in Python code. I’ll use pytest for demonstration.
Unit Testing
Here’s a basic unit test for Python’s absolute value function:
We can clearly see that the Arrange-Act-Assert pattern works for feature tests as well as unit tests.
The Arrange step forms the endpoint URL for searching for “Python Programming.” Notice the base URL and the query parameters.
The Act steps call the API using the URL using “requests” and then parse the response’s body from JSON into a Python dictionary.
The Assert steps then verify that the HTTP status code was 200, meaning “OK” or “success,” and that the word “Python” appears somewhere in the response’s abstract text.
Arrange-Act-Assert also works for other types of feature tests, like Web UI and mobile tests.
More Advice
Arrange-Act-Assert is powerful because it is simple. It forces tests to focus on independent, individual behaviors. It separates setup actions from the main actions. It requires test to make verifications and not merely run through motions. Notice how the pattern is not Arrange-Act-Assert-Act-Assert – subsequent actions and assertions belong in separate tests! Arrange-Act-Assert is a great pattern to follow for writing good functional tests.
Someone recently asked me the following question, which I’ve paraphrased for better context:
Is it good practice to use multiple test frameworks simultaneously? For example, I’m working on a Python project. I want to do BDD with behave for feature testing, but pytest would be better for unit testing. Can I use both? If so, how should I structure my project(s)?
The short answer: Yes, you should use the right frameworks for the right needs. Using more than one test framework is typically not difficult to set up. Let’s dig into this.
The F-word
I despise the F-word – “framework.” Within the test automation space, people use the word “framework” to refer to different things. Is the “framework” only the test package like pytest or JUnit? Does it include the tests themselves? Does it refer to automation tools like Selenium WebDriver?
For clarity, I prefer to use two different terms: “framework” and “solution.” A test framework is software package that lets programmers write tests as methods or functions, run the tests, and report the results. A test solution is a software implementation for a testing problem. It typically includes frameworks, tools, and test cases. To me, a framework is narrow, but a solution is comprehensive.
The original question used the word “framework,” but I think it should be answered in terms of solutions. There are two potential solutions at hand: one for unit tests written in pytest, while another for feature tests written in behave.
One Size Does Not Fit All
Always use the right tools or frameworks for the right needs. Unit tests and feature tests are fundamentally different. Unit tests directly access internal functions and methods in product code, whereas feature tests interact with live versions of the product as an external user or caller. Thus, they need different kinds of testing solutions, which most likely will require different tools and frameworks.
For example, behave is a BDD framework for Python. Programmers write test cases in plain-language Gherkin with step definitions as Python functions. Gherkin test cases are intuitively readable and understandable, which makes them great for testing high-level behaviors like interacting with a Web page. However, BDD frameworks add complexity that hampers unit test development. Unit tests are inherently “code-y” and low-level because they directly call product code. The pytest framework would be a better choice for unit testing. Conversely, feature tests could be written using raw pytest, but behave provides a more natural structure for describing features. Hence, separate solutions for different test types would be ideal.
Same or Separate Repositories?
If more than one test solution is appropriate for a given software project, the next question is where to put the test code. Should all test code go into the same repository as the product code, or should they go into separate repositories? Unfortunately, there is no universally correct answer. Here are some factors to consider.
Unit tests should always be located in the same repository as the product code they test. Unit tests directly depend upon the product code. They mus be written in the same language. Any time the product code is refactored, unit tests must be updated.
Feature tests can be placed in the same repository or a separate repository. I recommend putting feature tests in the same repository as product code if feature tests are written in the same language as the product code and if all the product code under test is located in the same repository. That way, tests are version-controlled together with the product under test. Otherwise, I recommend putting feature tests in their own separate repository. Mixed language repositories can be confusing to maintain, and version control must be handled differently with multi-repository products.
Same Repository Structure
One test solution in one repository is easy to set up, but multiple test solutions in one repository can be tricky. Thankfully, it’s not impossible. Project structure ultimately depends upon the language. Regardless of language, I recommend separating concerns. A repository should have clearly separate spaces (e.g., subdirectories) for product code and test code. Test code should be further divided by test types and then coverage areas. Testers should be able to run specific tests using convenient filters.
Here are ways to handle multiple test solutions in a few different languages:
In Python, project structure is fairly flexible. Conventionally, all tests belong under a top-level directory named “tests.” Subdirectories may be added thereunder, such as “unit” and “feature”. Frameworks like pytest and behave can take search paths so they run the proper tests. Furthermore, if using pytest-bdd instead of behave, pytest can use the markings/tags instead of search paths for filtering tests.
In .NET (like C#), the terms “project” and “solution” have special meanings. A .NET project is a collection of code that is built into one artifact. A .NET solution is a collection of projects that interrelate. Typically, the best practice in .NET would be to create a separate project for each test type/suite within the same .NET solution. I have personally set up a .NET solution that included separate projects for NUnit unit tests and SpecFlow feature tests.
In Java, project structure depends upon the project’s build automation tool. Most Java projects seem to use Maven or Gradle. In Maven’s Standard Directory Layout, tests belong under “src/test”. Different test types can be placed under separate packages there. The POM might need some extra configuration to run tests at different build phases.
In JavaScript, test placement depends heavily upon the project type. For example, Angular creates separate directories for unit tests using Jasmine and end-to-end tests using Protractor when initializing a new project.
Do What’s Best
Different test tools and frameworks meet different needs. No single one can solve all problems. Make sure to use the right tools for the problems at hand. Don’t force yourself to use the wrong thing simply because it is already used elsewhere.
Although the news of PyCon’s cancellation is not surprising, it is nevertheless devastating for members of the Python community. Here’s why it hurts, from the perspective of a full-hearted Pythonista, and here’s what we can do about it.
Python is Community-Driven
A frequent adage among Pythonistas is, “Come for the language, and say for the community.” I can personally attest to this statement for myself. When I started using Python in earnest in 2015, I loved how clean, concise, and powerful the language was. I didn’t fully engage the Python community until PyCon 2018, but once I did, I never left because I felt like I became part of something greater than just a bunch of coders.
Python is community-driven. There’s no major company behind the Python language, like Oracle for Java or Microsoft for .NET. Pythonistas keep Python going, whether that’s by being a Python language core developer, a third-party package developer, a conference organizer, a meetup volunteer, a corporate sponsor, or just a coder using Python for projects. And the people in the community are awesome. We help each other. We support each other. We eschew arrogance, champion diversity, and practice inclusivity.
PyCon US is the biggest worldwide Python event of the year. Thousands of Pythonistas from around the world join together for days of tutorials, talks, and sprints. This is the only time that many of us get to see each other in person together. It’s also the only way some of us would have ever met each other. I think of my good mate Julian, co-founder of PyBites. We met by chance at PyCon 2018 in the “hallway track” (meaning, just walking around and meeting people), and we hit it off right away. Julian lives in Australia, while I live in the United States. We probably would never have met outside of PyCon. Since then, we’ve done video chats together and promoted each other’s blogs. We spent much time together at PyCon 2019 and hoped to have another blast at PyCon 2020. We even had plans for a bunch of us content developers to get together to party. Unfortunately, that time together must be postponed until 2021.
There are several other individuals I could name in addition to Julian, too. I’m sure there are several other groups of friends throughout the community who look to PyCon as the time to meet. Losing that opportunity is heartbreaking.
PyCon is a Spectacle
PyCon itself is not just a conference – it’s a spectacle. PyCon is the community’s annual celebration of creativity, innovation, and progress. Talks showcase exciting projects. Tutorials shed deep expertise on critical subjects. Sprints put rocket boosters underneath open source projects to get work done. Online recordings become mainstay resources for the topics they cover. Becoming a speaker at PyCon is truly a badge of honor. Sponsors shower attendees with more swag than a carry-on bag can hold: t-shirts, socks, stickers, yo-yos, autographed books, iPads, water bottles, gloves, Pokémon cards; the list goes on and on. Many sponsors even host after-parties with dinner and drinks. All of these activities combined make PyCon much more than just another conference or event.
PyCon is truly a time to shine. Anyone who attends PyCon catches the magic in the air. There’s an undeniable buzz. And the anticipation leading up to PyCon can be unbearable. It’s like when kids go to Disney World. I can’t tell you how many friends I’ve encouraged to go to PyCon.
At PyCon 2020, we had much to celebrate. Python is now one of the world’s most popular programming languages, according to several surveys. Python 2 reached end-of-life on January 1. There are more Python projects and resources than ever before. 2020 is also the start of a new decade. We can still celebrate them, but not en masse at PyCon this year.
PyCon Supports the PSF
The Python Software Foundation (PSF) is the non-profit organization that supports the Python language and community. Here’s what they do, copied directly from their website:
The Python Software Foundation (PSF) is a 501(c)(3) non-profit corporation that holds the intellectual property rights behind the Python programming language. We manage the open source licensing for Python version 2.1 and later and own and protect the trademarks associated with Python. We also run the North American PyCon conference annually, support other Python conferences around the world, and fund Python related development with our grants program and by funding special projects.
PyCon is a major source of revenue for the PSF. I don’t know the ins and outs of the numbers, but I do know that cancelling PyCon will financially hurt the PSF, which will then affect what the PSF can do to carry out its mission. That’s no bueno.
What Can We Do?
Python is community-driven, and we are not powerless. Here are some things we can do as Pythonistas in light of PyCon 2020’s cancellation:
Support the Python Software Foundation. Openly and publicly thank the PSF for everything they have done. Offer heartfelt sympathies for the incredibly tough decisions they’ve had to make in recent weeks, because they made the unquestionably right decision here.
Join the Python Software Foundation. Anyone can become a member. There are varying levels of membership and commitment. Check out the PSF Membership FAQ for more info. Donations will greatly help the PSF through this tough time.
Engage your local Python community. The Python community is worldwide. Look for a local meetup. Attend regional Python conferences if possible – PyCon isn’t the only Python conference! The closest ones to where I live are PyGotham, PyOhio, and PyTennessee, and I’m helping to re-launch PyCarolinas.
Engage the online Python community. Even though many of us are practicing social distancing due to COVID-19, we can still keep in touch through the Internet. Support each other. Be intentional with good communication. Personally, I started using the hashtag #PythonStrong on Twitter.
Stay safe. COVID-19 is serious. Wherever you are, be smart and do the right things. For folks like me in the United States, that means social distancing right now.
Attend PyCon 2021. Since PyCon 2020 will be cancelled, we ought to make PyCon 2021 the best PyCon ever.
Python Strong
PyCon 2020’s cancellation is devastating but necessary. We shall overcome. Stay safe out there, Pythonistas. Stay #PythonStrong!
Hello World! I’d like to give an update on the PyCarolinas 2020 conference, since we’ve been quiet for quite some time. I’ll share what we’ve done and a new vision for where we want to go, especially given current world events.
How We Got Started
Calvin Spealman founded “PyCarolinas” in 2012 with the first (and so far only) conference at UNC Chapel Hill. The only other Python conference held in the Carolinas since then was PyData Carolinas 2016, hosted by IBM. Despite having several talented Pythonistas in both North and South Carolina, various factors prevented the return of either conference.
I first encountered the Python community when I delivered my first conference talk ever at PyData Carolinas 2016. However, I really became engaged at PyCon 2018, an experience that forever changed my life. I started speaking at several Python conferences around North America. The people I met became dear friends, and the ideas I learned inspired me to be a better Pythonista. However, one thing disappointed me: my home state didn’t have a regional Python conference. I wanted to bring the awesomeness of a Python conference to my backyard so that others could join the fun.
During PyCon 2019, I shared this idea with some friends, and every one of them said that we should make it happen. A few of us attended an open space for conference organizers to swap ideas. Dustin Ingram then invited me to give a call-to-action for a PyCarolinas 2020 conference on the big stage during the “parade of worldwide conferences.” Immediately thereafter, I held an open space for PyCarolinas to kick things off, and dozens of people attended. We created a Slack room, launched a newsletter, and started a Twitter storm. I got in touch with Calvin so we could formally plan things together. Calvin secured a venue at the Red Hat Annex for June 20-21. We even created a logo and took Code of Conduct training by invitation of our wonderful PyGotham friends. Things were looking bright.
Well, What Happened?
Life happened. From November until now, I personally had to handle several personal and family matters, in addition to holidays, my full-time job, and various commitments. You can read the full story here. Calvin also had things come up. As a result, PyCarolinas progress was minimal. We brought together a community, but we failed to meet critical milestones. I personally take responsibility for those failures.
There’s also a new monkey wrench in our plans: COVID-19. The coronavirus is starting to spread throughout the United States, and North Carolina is already in a state of emergency due to multiple local cases. Other conferences like SXSW 2020 and E3 have been canceled. At the time of writing this article, PyCon 2020 might be canceled or postponed. We just don’t know how things will be by June. We would hate to put a lot of work into PyCarolinas 2020 if it could be canceled due to COVID-19, especially when we are already behind schedule.
A New Way Forward
Personally, I was ready to give up and recommend that we cancel PyCarolinas 2020. Then, while returning from PyTennessee 2020, I had a stroke of inspiration:
What if we made PyCarolinas 2020 an “unconference”?
Traditional conferences take a lot of top-down planning and hard commitments, which is not something we can or should do right now. Unconferences, on the other hand, are participant-driven. Their organization is lean: provide a space for people to gather, collaborate, and cross-pollinate.
Here’s the new vision I’d like to cast for a PyCarolinas 2020 Unconference:
One day only: Saturday, June 20 at Red Hat Annex
Lightning talks only: no lengthy CFP; informal sign-ups beforehand
Maybe a keynote speaker
Open collaboration spaces in the other rooms
Set aside time for organizers to seriously plan PyCarolinas 2021
Limit sponsorships for simplicity
Uphold the Python community’s Code of Conduct
Offer only about 100 tickets to keep the event small
Encourage local and regional attendance
Empower the Python community to be awesome!
Furthermore, I would like to offer tickets for FREE! Free tickets would allow anyone to come, and they would also help us as organizers avoid the hassle of money changing hands, bank accounts, and legal entities for this event.
Red Hat has already graciously provided a venue for free. I’d like to find a sponsor to provide pizza and soft drinks for lunch. If possible, I’d also like to find a sponsor to print some stickers.
By keeping this event lean, we win both ways. If COVID-19 is no longer an issue by June, then we get to lead a truly unique type of Python regional conference. If COVID-19 is still a problem, then we can easily postpone the event without much loss or pain.
The Next Steps
I’ve shared this idea with a few friends (including Calvin), and everyone so far agrees that this is a good path forward. In the coming days, we will share this plan to make sure the community agrees. Then, if this is the way, we can launch a very simple website, set up ticketing, and find someone to sponsor pizza.
Personally, I feel good about this idea. It’s a big relief to downsize. Deep down, I know I can trust the Python community to make this unique type of conference a hit.
Don’t understand my Chinese? Don’t feel bad – I don’t know much Mandarin, either! My wife and her mom are from China. When I developed a Django app to help my wife run her small business, I needed to translate the whole site into Chinese so that Mama could use it, too. Thankfully, Django’s translation framework is top-notch.
“East Meets West When Translating Django Apps” is the talk I gave about translating my family’s Django app between English and Chinese. For me, this talk had all the feels. I shared my family’s story as a backdrop. I showed Python code for each step in the translation workflow. I gave advice on my lessons learned. And I spoke truth to power – that translations should bring us all together.
Python is hot right now. Recently, several people have asked me how they can start learning Python. Here are my answers, nuanced by goals and roles.
I’m completely new to programming. How can I start learning Python?
That’s awesome! Python is a great language for beginners. You can do just about anything with Python, and its learning curve is lower than other languages. Here’s what I recommend:
First, find a friend who knows Python. They can encourage you in your journey and also help you when you get stuck. If you need help finding Python friends, look for a local Python meetup, or just reach out to me.
Second, install the latest version of Python from Python.org onto your computer. If you want to learn Python, then you’ll need to get your hands dirty!
Third, read through a good Python book for beginners. Despite all the material available online, nothing beats a good book. I recommend Automate the Boring Stuff with Python by Al Sweigart. It’s a book written specifically for people who are new to coding, and it shows very practical things you can do with Python. You can even read it for free online! Udemy also offers an online course based on this book. Make sure you follow along with the example code on your own machine.
Once you finish your first book, keep learning! Try another book. Take an online course. Come up with a fun project you can do yourself, like making a website or programming a circuit board.
I’m a hobbyist. How can I start learning Python for fun?
Python is a great language for fun side projects. It’s easy to learn, and it has tons of packages to do just about anything. If you just want to start programming in general, then I’d recommend reading Automate the Boring Stuff with Python by Al Sweigart or Python Crash Course by Eric Matthes. No Starch Press also publishes a number of other Python books on nifty topics like games, math, and ciphers.
If you’re a hobbyist, then my main recommendation would be to come up with a fun project. Learning Python by itself is great, but learning Python to do a cool project will keep you motivated with a clear goal. Here are some ideas:
I’m a software engineer. How can I pick up Python quickly?
If you already know how to code, and you just need to pick up Python for a project on the job, don’t fret. Python will be very quick to pick up. When I re-learned Python a few years ago, I read the Python Programming book on Wikibooks. Learn X in Y Minutes and learnpython.org are also great resources for learning quickly by example. Once you breeze through the language, then you’ll probably need to lear packages and frameworks specific to your project. Some projects have better docs than others. For example, Django and pytest have great docs online.
I’m a scientist. Should I start using Python, and if so, how?
Data scientists were the first scientific community to adopt Python in large numbers, but now scientists from all fields use it for data analysis and visualization. I personally know an environmental scientist and a virologist who both started using Python in the past few years. Compared to other languages like R and Julia, Python simply has more users, more packages, and more support. Furthermore, the Python Developers Survey 2018 showed that over half of all Python users use Python for data analysis. So yes, if you’re a scientist, then you should start using Python!
To get started with Python, first make sure you have basic programming skills. It might be tempting to dive headfirst into coding some data analysis scripts, but your work will turn out much better if you learn the basics first. If you are new to programming, then start by reading Automate the Boring Stuff with Python by Al Sweigart. To learn specifically about data analysis with Python, read Python for Data Analysis by William McKinney. I’d also recommend reading additional books or taking some courses on specific tools and frameworks that you intend to use. Furthermore, I’d yield my advice to any peers in your scientific community who have recommendations.
I’m a software tester. How can I start learning Python for automation?
Python is a great language for test automation. If you are a manual tester who hasn’t done any programming before, focus on learning how to code before learning how to do automation. Follow the advice I gave above for newbies. Once you have basic Python skills, then learn pytest, the most popular and arguably the best test framework for Python. I recommend reading pytest Quick Start Guide by Bruno Oliveira or Python Testing with pytest by Brian Okken. If you want to learn about Test-Driven Development with a Django app, then check out the goat book by Harry Percival.
I’m a kid. Are there any good ways for me to learn Python?
Yes! Python is a great language for kids as well as adults. Its learning curve is low, but it still has tons of power. No Starch Press publishes a few Python books specifically for kids. Project kits from Adafruit and Raspberry Pi are another great way for kids to get their hands dirty with fun projects. If you want to learn by making games, check out Arcade Academy or PursuedPyBear. Many Python conferences also run “Young Coders” events that encourage kids to come and do things with Python.
Should I learn Python, JavaScript, Java, or another language?
Each programming language has advantages and disadvantages, but the main factor in choosing a language should be what you intend to develop. For example, Web app front-ends require JavaScript because browsers use JavaScript and not other languages. Java is popular all around for several applications like backend services and Android apps. C# is a mainstay for Microsoft .NET development. Python excels at backend web development, infrastructure, automation, and data science.
If you are new to programming and just want to start somewhere, I’d strongly recommend Python. Compared to other programming languages, it’s easy to learn. As you grow your skills, Python will grow with you because it has so many packages. You can also explore a variety of interest within the Python community because Python is popular in many domains. These days, you just can’t go wrong learning Python!
Should I learn Python 2 or 3?
Learn Python 3. Python 2 hit end of life on January 1, 2020. Some older projects may continue to use Python 2, but support for Python 2 is dead.
What tools should I use for coding in Python?
The most important tool for coding in any language is arguably the editor or IDE. These days, I use Visual Studio Code with the Python extension. VS Code feels lightweight, but it provides all the things I need as a developer: syntax highlighting, running and debugging, Git integration, and a terminal in the same window. VS Code is also fully customizable. JetBrains PyCharm is another great editor that I recommend. PyCharm a bit heavier than VS Code, but it also has richer features. Both are fantastic choices.
Virtual environments are indispensable part of Python development. They manage Python dependency packages locally per project rather than globally for an entire machine. Local package management is necessary when a user doesn’t have system-wide access or when a project needs a different package version than the one installed globally. To learn about virtual environments, take the venv tutorial in the official Python docs.
Source control is another vital part of programming. Using a source control system like Git maintains a history of your project. If you ever make a mistake, you can revert the code to its last known working state. Source control also makes it much easier for multiple people to work on the same project together simultaneously. Git is one of the most popular source control tools in use today. To learn more about Git, check out GitHub’s learning resources.
What Python books should I read?
Please check my suggestions above to know what Python books could be good for you.
What Python courses should I take online?
To be honest, I don’t have any specific Python courses to recommend. Most online courses are very similar. They include videos, transcripts, quizzes, and maybe even projects. If you want to take an online course, then I recommend finding one that looks good to you and giving it a try. I also recommend using multiple resources – either taking more than one course or reading more than one book. The second pass will reinforce the basics and also reveal new tidbits that the first pass may have missed.
Should I take a Python boot camp?
Boot camps are high-intensity programs that train people to become developers. Many boot camps focus on one main technology stack or skill, such as Web development with JavaScript or data science with Python. They can take weeks or months of full-time focus to complete, and they can be expensive.
Boot camp isn’t right for everyone. Most people go to boot camp in order to find a job after completing the program. They can be a great way to pivot your career if you seriously want to become a software developer but don’t want to go “back to school.” However, they may not be ideal if you just want to learn programming for fun or as a secondary skill.
Personally, I don’t have any boot camps to recommend, but I do know that most major US cities have boot camp programs. If you think boot camp is right for you, then check them out.
Should I go to a Python conference?
YES! Absolutely yes! People come to Python for the language, but they stay for the people. Python conferences are the best way to engage the Python community. They are places to learn and be inspired. You’ll also score tons of cool swag. Lives change at Python conferences.
The main Python conference is PyCon US. Thousands of people attend each year. However, there are several other Python conferences worldwide and regionally around the US. Personally, I’ve been to PyCon, PyOhio, PyGotham, PyCon Canada, PyCaribbean, PyTexas, PyCascades, DjangoCon, and PyData Carolinas. Try to find a regional conference near you if you can’t make it to PyCon.
What are common Python interview questions?
Most interviews I’ve taken focus more on general engineering skills rather than pure language trivia. Nevertheless, if you are pursuing a role that requires Python programming, then you should be prepared for some Python-oriented questions. Online articles like Toptal’s How to Hire a Great Python Developer and Interview Cake’s Python Interview Questions reveal things that a candidate should know about Python.
How much will it cost to use and learn Python?
It’s possible to learn and use Python for free! Python is an open source language. As long as you have a machine with Internet access, you can download Python for free and get rolling. There are tons of free learning resources online, too. Typically, you can learn the basics for free, but you might want to buy some books or courses for specific tools or frameworks.
Automation Panda 