Python

Python Testing 101: pytest-bdd

Warning: If you are new to BDD, then I strongly recommend reading the BDD 101 series before trying to use pytest-bdd. Also, make sure that you are already familiar with the pytest framework.

Overview

pytest-bdd is a behavior-driven (BDD) test framework that is very similar to behaveCucumber and SpecFlow. BDD frameworks are very different from more traditional frameworks like unittest and pytest. Test scenarios are written in Gherkin “.feature” files using plain language. Each Given, When, and Then step is “glued” to a step definition – a Python function decorated by a matching string in a step definition module. This means that there is a separation of concerns between test cases and test code. Gherkin steps may also be reused by multiple scenarios.

pytest-bdd is very similar to other Python BDD frameworks like behave, radish, and lettuce. However, unlike the others, pytest-bdd is not a standalone framework: it is a plugin for pytest. Thus, all of pytest‘s features and plugins can be used with pytest-bdd. This is a huge advantage!

Installation

Use pip to install both pytest and pytest-bdd.

pip install pytest
pip install pytest-bdd

Project Structure

Project structure for pytest-bdd is actually pretty flexible (since it is based on pytest), but the following conventions are recommended:

  • All test code should appear under a test directory named “tests”.
  • Feature files should be placed in a test subdirectory named “features”.
  • Step definition modules should be placed in a test subdirectory named “step_defs”.
  • conftest.py files should be located together with step definition modules.

Other names and hierarchies may be used. For example, large test suites can have feature-specific directories of features and step defs. pytest should be able to discover tests anywhere under the test directory.

[project root directory]
|‐‐ [product code packages]
|-- [test directories]
|   |-- features
|   |   `-- *.feature
|   `-- step_defs
|       |-- conftest.py
|       `-- test_*.py
`-- [pytest.ini|tox.ini|setup.cfg]

Note: Step definition module names do not need to be the same as feature file names. Any step definition can be used by any feature file within the same project.

Example Code

An example project named behavior-driven-python located in GitHub shows how to write tests using pytest-bdd. This section will explain how the Web tests are designed.

The top layer for pytest-bdd tests is the set of Gherkin feature files. Notice how the scenario below is concise, focused, meaningful, and declarative:

@web @duckduckgo
Feature: DuckDuckGo Web Browsing
  As a web surfer,
  I want to find information online,
  So I can learn new things and get tasks done.

  # The "@" annotations are tags
  # One feature can have multiple scenarios
  # The lines immediately after the feature title are just comments

  Scenario: Basic DuckDuckGo Search
    Given the DuckDuckGo home page is displayed
    When the user searches for "panda"
    Then results are shown for "panda"

Each scenario step is “glued” to a decorated Python function called a step definition. Step definitions are written in Python test modules, as shown below:

import pytest
from pytest_bdd import scenarios, given, when, then, parsers
from selenium import webdriver
from selenium.webdriver.common.keys import Keys

# Constants

DUCKDUCKGO_HOME = 'https://duckduckgo.com/'

# Scenarios

scenarios('../features/web.feature')

# Fixtures

@pytest.fixture
def browser():
    b = webdriver.Firefox()
    b.implicitly_wait(10)
    yield b
    b.quit()

# Given Steps

@given('the DuckDuckGo home page is displayed')
def ddg_home(browser):
    browser.get(DUCKDUCKGO_HOME)

# When Steps

@when(parsers.parse('the user searches for "{phrase}"'))
def search_phrase(browser, phrase):
    search_input = browser.find_element_by_name('q')
    search_input.send_keys(phrase + Keys.RETURN)

# Then Steps

@then(parsers.parse('results are shown for "{phrase}"'))
def search_results(browser, phrase):
    links_div = browser.find_element_by_id('links')
    assert len(links_div.find_elements_by_xpath('//div')) > 0
    search_input = browser.find_element_by_name('q')
    assert search_input.get_attribute('value') == phrase

Notice how each Given/When/Then step has a function with an appropriate decorator. Arguments, such as the search “phrase,” may also be passed from step to function. pytest-bdd provides a few argument parsers out of the box and also lets programmers implement their own. (By default, strings are compared using equality.) One function can be decorated for many steps, too.

pytest fixtures may also be used by step functions. The code above uses a fixture to initialize the Firefox WebDriver before each scenario and then quit it after each scenario. Fixtures follow all the same rules, including scope. Any step function can use a fixture by declaring it as an argument. Furthermore, any “@given” step function that returns a value can also be used as a fixture. Please read the official docs for more info about fixtures with pytest-bdd.

One important, easily-overlooked detail is that scenarios must be explicitly declared in test modules. Unlike other BDD frameworks that treat feature files as the main scripts, pytest-bdd treats the “test_*.py” module as the main scripts (because that’s what pytest does). Scenarios may be specified explicitly using scenario decorators, or all scenarios in a list of feature files may be included implicitly using the “scenarios” shortcut function shown above.

To share steps across multiple feature files, add them to the “conftest.py” file instead of the test modules. Since scenarios must be declared within a test module, they can only use step functions available within the same module or in “conftest.py”. As a best practice, put commonly shared steps in “conftest.py” and feature-specific steps in the test module. The same recommendation also applies for hooks.

Scenario outlines require special implementation on the Python side to run successfully. Unfortunately, steps used by scenario outlines need unique step decorators and extra converting. Please read the official docs or the example project to see examples.

Test Launch

pytest-bdd can leverage the full power of pytest. Tests can be run in full or filtered by tag. Below are example commands using the example project:

# run all tests
pytest

# filter tests by test module
# note: feature files cannot be run directly
pytest tests/step_defs/test_unit_basic.py
pytest tests/step_defs/test_unit_outlines.py
pytest tests/step_defs/test_unit_service.py
pytest tests/step_defs/test_unit_web.py

# filter tests by tags
# running by tag is typically better than running by path
pytest -k "unit"
pytest -k "service"
pytest -k "web"
pytest -k "add or remove"
pytest -k "unit and not outline"

# print JUnit report
pytest -junitxml=/path/for/output

pytest-bdd tests can be executed and filtered together with regular pytest tests. Tests can all be located within the same directory. Tags work just like pytest.mark.

All other pytest plugins should work, too. For example:

Pros and Cons

Just like for other BDD frameworks, pytest-bdd is best suited for black-box testing because it forces the developer to write test cases in plain, descriptive language. In my opinion, it is arguably the best BDD framework currently available for Python because it rests on the strength and extendability of pytest. It also has PyCharm support (in the Professional Edition). However, it can be more cumbersome to use than behave due to the extra code needed for declaring scenarios, implementing scenario outlines, and sharing steps. Nevertheless, I would still recommend pytest-bdd over behave for most users because it is more powerful – pytest is just awesome!

Speaking Pythonese

The Python community, like many groups, has its own language – and I don’t mean just Python. There are many words and phrases thrown around that may confuse people new to Python. I originally shared some terms in my article, Which Version of Python Should I Use?, but below are some more of those colloquialisms for quick reference:

Word or Phrase Meaning
Anaconda
  • Open-source implementation of Python (and R)
  • Meant for data scientists
  • Uses the conda package manager
Benevolent Dictator for Life (BDFL)
  • Guido van Rossum
  • The inventor of Python
  • Resigned in July 2018 but remains BDFL Emeritus
The CheeseShop
  • a fun code name for the Python Package Index
Class
  • A programming definition for creating objects
  • Combines attributes (variables) and behaviors (methods)
  • Useful for reusing code
Conda
  • Package manager for Python and other languages
  • Part of the Anaconda project
Core Developer
  • A developer who has commit privilege to the CPython codebase
  • Very few Pythonistas are core developers
CPython
  • The default and most widely used implementation of the Python language
  • Implemented in C
Django
  • A batteries-included Python Web framework for perfectionists with deadlines
  • Offers many features out of the box
  • The most popular Python framework in 2017
  • Size: Flask < Pyramid < Django
Flask
  • A microframework for Python Web development
  • Uses Werkzeug and Jinja2
  • Super-minimalist
  • Size: Flask < Pyramid < Django
Function
  • A definition for a callable subroutine
  • May take inputs
  • May return outputs
  • Great for code reuse
  • Functions are first-order values
The Hitchhiker’s Guide to Python
  • A popular online guide to Python
  • Opinionated
  • Shares many good best practices
Jinja2
  • A Python template engine
  • Inspired by Django’s templates
Jupyter
  • A project for interactive Python development
  • “Jupyter Notebooks” allow programmers to dynamically rewrite and rerun Python code, and then share code easily with others
  • Popular with data scientists
Module
  • A Python source code file containing definitions and statements
  • Every .py file is a module
  • May be imported by other modules to reuse code
NumPy
  • A popular Python package for scientific computing
Pandas
  • A popular Python package for data analysis
pip
  • The PyPA-recommended tool for installing Python packages
  • Command: “pip install “
  • Recursive acronym for “pip installs packages”
PyBites
  • A community of Pythoneers who improve their skills through code challenges
PyCharm
  • A popular Python IDE developed by JetBrains
  • Offers great development features
  • Has a free Community Edition and a paid Professional Edition
PyCon
  • The annual Python conference held in North America
  • GO – it will change your life!
  • Several other conferences are held worldwide
PyPy
  • An alternative Python implementation
  • Known for speed, memory usage, and compatibility
  • Good alternative to CPython for high performance workloads
Pyramid
  • A Python Web framework
  • Start small, finish big, stay finished
  • Provides many parts but not everything (such as ORM)
  • Size: Flask < Pyramid < Django
pytest
  • A lightweight-yet-powerful Python test framework (and arguably the best)
Python 2
  • The old version of Python
  • Will reach end-of-life in 2020
  • Final version will be 2.7.x
  • Please upgrade to version 3
Python 3
  • The current version of Python
  • Most packages now support Python 3
  • Has incompatibilities with Python 2
  • Please don’t use Python 2
Python Enhancement Proposal (PEP)
  • Official proposals for enhancing the Python language
Python Package Index (PyPI)
The Python Software Foundation (PSF)
  • Non-profit organization
  • Keeps Python going strong
  • Support them!
Pythoneer
  • A programmer who uses Python to solve problems
  • Styled off the word “engineer”
Pythonic
  • Describes idiomatic code for Python
  • Closely related to conciseness, readability, and elegance
  • Highly recommended
  • Follow style guidelines to learn how to be Pythonic
Pythonista
  • Someone who loves the Python language
  • Often an advanced Python programmer
Sphinx
  • A popular Python tool to generate documentation
virtualenv
  • Tool to create isolated Python environments
  • Enables programmers to use different versions of Python and packages for different projects
  • Also see venv and pipenv
Web Server Gateway Interface (WSGI)
  • A specification for how Web servers forward requests to Web applications and frameworks
  • A core piece of Python Web development
  • See PEP-333 and PEP-3333
The Zen of Python
  • The list of guiding principles for Python’s design
  • Run “import this” to see them
  • See PEP-20

Book Review: pytest Quick Start Guide

tl;dr

Title pytest Quick Start Guide
(available from Packt and Amazon)
Author Bruno Oliveira (@nicoddemus)
Publication 2018 Packt Publishing
Summary “Write better Python code with simple and maintainable tests” – a very readable guide for pytest’s main features.
Prerequisites Intermediate-level Python programming.

Summary

pytest Quick Start Guide is a new book about using pytest for Python test automation. Bruno Oliveira explains not only how to use pytest but also why its features are useful. Even though this book is written as a “quick start” introduction, it nevertheless dives deep into pytest’s major features. It covers:

  1. An introduction to pytest
  2. Why pytest is superior to unittest
  3. Setting up pytest with pip and virtualenv
  4. Writing basic tests
  5. How assertions really work
  6. Common command line arguments
  7. Marks and parametrization
  8. Using and writing fixtures
  9. Popular plugins
  10. Converting unittest suites to pytest

Example code is hosted on GitHub at PacktPublishing/pytest-Quick-Start-Guide.

Praises

This book is an easy introduction to test automation in Python with pytest. Readers should have intermediate-level Python skills, but they do not need previous testing or automation skills. The progression of chapters makes it easy to start quick and then go deeper. Oliveira has a very accessible writing style, too.

The unittest refactoring guide is a hidden gem. The unittest module is great because it comes bundled with Python, but it is also clunky and not very Pythonic. Not all teams know the best way to modernize their test suites. Oliveira provides many pieces of practical advice for making the change, at varying degrees of conversion. The big changes use pytest’s fixtures and assertions.

A Comparison to Python Testing with pytest

Python Testing with pytest by Brian Okken is another popular pytest book. Both books are great resources for learning pytest, but each approaches the framework from a unique perspective. How do they compare? Here’s what I saw:

Oliveira’s book Okken’s book
Oliveira’s book is a great introductory guide for pytest. Oliveira’s writing style makes the reader feel like the author is almost teaching in person. The book’s main theme is getting the reader to use the main features of pytest pragmatically for general testing needs. The main differences in content are the unittest refactoring guide and some of the plugins and fixtures covered. This book is probably the best choice for beginners who want to learn the basics of pytest quickly. Okken’s book is introductory but also a great manual for future reference. Okken’s writing style is direct and concise, which covers more material in fewer pages. The format for each chapter is consistent: for each idea: idea → code → output → explanation; exercises at the end. Okken also covers how to create and share custom pytest plugins. This book is probably the best choice for people who want to master the ins and outs of pytest.

Ultimately, I recommend both books because they are both excellent.

Takeaways

Reading books on the same subject by different authors helps the reader learn the subject better. I’ve used pytest quite a lot myself, but I was able to learn new things from both pytest Quick Start Guide and Python Testing with pytest. Reading how experts use and think about the framework makes me a better engineer. Different writing styles and different opinions also challenge my own understandings. (It’s also funny that the authors of both pytest books have the same initials – “B.O.”)

pytest is really popular. There are now multiple good books on the subject. It’s becoming the de facto test automation framework for Python, outpacing unittest, nose, and others. These days, it seems more popular to write a pytest plugin than to create a new framework.

Book Review: Python Testing with pytest

tl;dr

Title Python Testing with pytest
Author Brian Okken (@brianokken)
Publication 2017 (The Pragmatic Programmers)
Summary How to use all the features of pytest for Python test automation – “simple, rapid, effective, and scalable.”
Prerequisites Intermediate-level Python programming.

Summary

Python Testing with pytest is the book on pytest*. Brian Okken covers all the ins and outs of the framework. The book is useful both as tutorial for learning pytest as well as a reference for specific framework features. It covers:

  • Getting started with pytest
  • Writing simple tests as functions
  • Writing more interesting tests with assertions, exceptions, and parameters
  • Using all the different execution options
  • Writing fixtures to flexibly separate concerns and reuse code
  • Using built-in fixtures like tmpdir, pytestconfig, and monkeypatch
  • Using configuration files to control execution
  • Integrating pytest with other tools like pdb, tox, and Jenkins

Appendices also cover:

  • Using Python virtual environments
  • Installing packages with pip
  • An overview of popular plugins like pytest-xdist and pytest-cov
  • Packaging and distributing Python packages

[* Update on 9/27/2018: Check out my review on another excellent pytest book, pytest Quick Start Guide by Bruno Oliveira.]

Praises

This book is a comprehensive guide to pytest. It thoroughly covers the framework’s features and gives pointers to more info elsewhere. Even though pytest has excellent online documentation, I still recommend this book to anyone who wants to become a pytest master. Online docs tend to be fragmented with each piece limited in scope, whereas books like this one are designed to be read progressively and orderly for maximal understanding of the material.

I love how this book is example-driven. Each section follows a simple yet powerful outline: idea → code → output → explanation. Having real code with real output truly cements the point of each mini-lesson. New topics are carefully unfolded so that they build upon previous topics, making the book read like a collection of tutorials. Examples at the end of every chapter challenge the readers to practice what they learn. The formatting of each section also looks great.

The extra info on related topics like pip and virtualenv is also a nice touch. Python pros probably don’t need it, but beginners might get stuck without it.

The rocket ship logo on the cover is also really cool!

Takeaways

pytest is one of the best functional test frameworks currently available in any language. It breaks the clunky xUnit mold, in which class structures were awkwardly superimposed over test cases as if one size fits all. Instead, pytest is lightweight and minimalist because it relies on functions and fixtures. Scope is much easier to manage, code is more reusable, and side effects can more easily be avoided. pytest has taken over Python testing because it is so Pythonic.

Brian’s concise writing style has also inspired me to be more direct in my own writing. I tend to be rather verbose out of my desire to be descriptive. However, fewer words often leave a more powerful impression. They also make the message easier to comprehend. Python is beloved for its concise expressiveness, and as a Pythonista, it would be fitting for me to adopt that trait into my English.

If I had a wish list for a second edition, I’d love to see more info about assertions and other plugins (namely pytest-bdd). I think an appendix with comparisons to other Python test frameworks would also be valuable.

A Warning

I ordered a physical copy of this book directly from Amazon (not a third-party seller). Unfortunately, that copy was missing all the introductory content: the table of contents, the acknowledgements, and the preface. The first page after the front cover was Chapter 1. Befuddled, I reached out to Brian Okken (who I personally met at PyCon 2018). We suspected that it was either a misprint or a bootleg copy. Either way, we sent the evidence to the publisher, and Amazon graciously exchanged my defective copy for the real deal. Please look out for this sort of problem if you purchase a printed copy of this book for yourself!

If you want to learn more about pytest, please read my article Python Testing 101: pytest.

Book Review: Hands-On Enterprise Automation with Python

tl;dr

Title Hands-On Enterprise Automation with Python (available from Amazon and Packt)
Author Bassem Aly
Publication 2018 (Packt Publishing)
Summary Using Python packages for network, system, and infrastructure automation.
Prerequisites Intermediate Python programming. Intermediate administrative skills.

Summary

Hands-On Enterprise Automation with Python is an excellent resource for learning how to automate common administrative tasks like running commands, scraping network config, and setting up systems. Python is a natural fit for such tasks with its impressive package library, its easy learning curve, and its concise syntax.

The number of Python tools and modules this book covers is stunning:

  • Developing Python code with PyCharm
  • Managing network devices with paramiko, netmiko, and telnetlib
  • Using regular expressions with re
  • Charting data with matplotlib
  • Templating YAML files with Jinja2
  • Multiprocessing with multiprocessing
  • Running local system commands with subprocess
  • Running remote system commands with fabric
  • Getting system info with platform
  • Sending emails with smtplib
  • System administration with Ansible
  • Interacting with a MySQL database using MySQLdb
  • Storing files in Amazon S3 using boto3
  • Packet sniffing and manipulating with scapy

Each new topic is introduced with background information, setup steps, and example code. Instructions are given for the reader to set up their own test environment and try things out. Later chapters also show how to use modules together to build more powerful automation. Most examples favor Python 2 but can be made compatible with Python 3.

Praises

The best thing about this book is how it covers an incredible breadth of topics in such a readable way. Rather than being dry manual pages pulled from a cryptic doc site, each chapter is a tutorial with explanations and real-world code examples. Readers can easily read through the book cover-to-cover or seek topics directly as a reference.

Another great thing is that the author always introduces new concepts before applying them. While intermediate skills with Python and administration are presumed as a prerequisite, the introductory chapters nevertheless show how to set up a full Python development environment with a network lab for testing. Before showing how to use any particular module, the author explains what the problem is and why the module should be used. This makes the material very accessible, especially for non-sysadmins.

Comments

  • The tasks showcased are network-heavy.
  • The setup primarily relies on Linux.
  • Many pages are dedicated to workbench setup.
  • Modules are covered at an introductory level and not in depth.

Takeaways

I thoroughly enjoyed reading Hands-On Enterprise Automation with Python. As a Software Engineer in Test, the word “automation” almost always means “test automation.” Reading this book was a healthy glimpse at other no-less-important types of automation oriented more toward admin tools and scripts. I could definitely leverage many of the modules covered in this book for my own work, too – several of them cross domains.

I really liked the three main reasons the author gave for using Python for automation: it is readable, it has so many libraries, and it has power in its conciseness. These reasons ring true for many applications, especially the point about modules. Since there’s a module for nearly everything, Python programming often simplifies to recipes for using those modules. Arguably, this book is a cookbook full of sysadmin recipes.

Reading this book also made me reminiscent of my days working at MaxPoint, where I first learned Python to build a test automation framework. I used many of the same modules shared in this book for the same tasks. I felt comfort in my familiarity and validation in my past efforts.

PyOhio 2018 Reflections

PyOhio 2018 was a free Python conference hosted at Ohio State University in Columbus, OH from July 28-29. I had the pleasure of not only attending but also speaking at PyOhio, and my company, PrecisionLender, graciously covered my travel expenses. I had a great time. Here’s my retrospective on the conference.

My Talk

The main reason I went to PyOhio was because I was honored to be a speaker. When I was at an Instagram dinner at PyCon 2018, I met a few conference organizers who encouraged me to propose talks at other Python conferences. On a whim the next morning, I spitballed an idea for a talk about building a test automation solution from the ground up in Python. After talking with a number of people, I realized how test automation is such a struggle everywhere. I took inspiration from Ying Li’s keynote and crafted a story about how Amanda the Panda, a Bamboozle employee, becomes a test automation champion. And, BOOM! My talk proposal was accepted for PyOhio and PyGotham! The video recording for my talk, “Egad! How Do We Start Writing (Better) Tests?”, is below:

Arrival

Good news: Raleigh and Columbus have direct flights. Bad news: they are either early-morning or late-night direct flights. So, I left Raleigh on Friday morning before the conference and spent the day in Columbus. Surprisingly, the security line at RDU wrapped around 2/3 of the Terminal 2 perimeter, but I still boarded the flight on time. Once I landed in Columbus, I took the COTA AirConnect bus downtown for the low price of $2.75.

My goal for Friday was personal development. I rarely get a chance to escape the rigors of everyday life to focus on myself. Personal retreats let me clear my mind, dream big, and begin taking action. And on this day, I started writing my first test automation book – a dream I’ve held for over a year now. I spent a few hours at Wolf’s Ridge Brewery, sampling beers with lunch as I developed a rough outline for my project.

My evening was low-key. I took a nap at my hotel, the Blackwell Inn and Pfahl Conference Center. For dinner, I ate at White Castle for the first time – and it was pretty darn good. After practicing my talk, I got a tiramisu bubble tea from Vivi as a night cap.

The Conference

PyOhio was a much smaller conference than PyCon. There were fewer vendor tables but nevertheless a wide selection of stellar talks. As a result, the conference felt more intimate and more focused. Perhaps that feeling was due also to the venue: the third floor of the Ohio Union had full rooms with “cozy” hallways. Hats off to the organizers, too – everything ran smoothly and professionally.

As soon as I arrived, I scored my name badge, my swag bag, and my official PyOhio 2018 t-shirt. The opening keynote from Adrienne Lowe, “From Support to Engineering and Beyond: What to Take with You, and What to Leave Behind,” about the highs and lows of trying to make it as a developer was exceptionally inspiring. Engineers often don’t talk about how hard the job is, especially for newcomers to the industry. Everybody suffers from imposter syndrome. Everybody feels inadequate. Everybody is tempted to quit, even to the point of tears. The vulnerability in hearing others say, “Me, too,” is so relatable and so relieving.

The first talk-talk I attended was Trey Hunner’s “Easier Classes: Python Classes Without All the Cruft.” Trey gave an excellent overview of writing more sophisticated Python classes. TL;DR: upgrade to 3.7 and use dataclasses.

The next talk I attended was Leo Guinan’s “Go with the Flow: Automating Your Workflows with Airflow.” Apache Airflow is a platform for automating workflows. As an automationeer, it struck me as being like a continuous integration system generalized for non-build purposes. The Q&A portion of the talk was lit.

After finding an authentic Chinese restaurant for lunch, my friend Matt arrived! I worked with Matt in the testing space at LexisNexis. He drove all the way from Dayton to see my talk and hang out. We spent the early afternoon catching up, and we went to Hook Hearted Brewing for dinner after the conference because we’re beer buddies. I was so thankful he came to support me – it meant a lot!

My talk was at 3:45pm. Other than discovering my Thunderbolt-to-HDMI adapter was a dud, the talk went very well. I decided to stick to a script for this talk because most of it followed a story, and I’m glad I did. (For my PyCon talk, I chose instead to speak without a script and rely instead on the slides alone.) There were about 30 people in the audience. Many expressed appreciation for my presentation!

The last talk of the day for me was Jace Browning’s “Automated Regression Testing with Splinter and Jupyter.” It was the perfect follow-up to my talk. Whereas mine was mostly high-level, Jace showed implementation and execution. I loved how he compared raw Selenium WebDriver calls to splinter calls, and I was thrilled to see hands-on test execution using Jupyter. One of the things that makes Python so great for automation is that modules can be called from the interpreter – and Jupyter notebooks make that so easy.

The Second Day

Sunday was a shorter conference day. The opening keynote, Lorena Mesa’s “Now is better than Never: What the Zen of Python can teach us about Data Ethics,” didn’t start until 11:40am. Lorena showed us what the Zen of Python can teach us about data ethics in a scary, modern world.

I got lunch at Chatime: dan dan noodles (or rather, an imitation thereof) and a matcha latte with grass jelly. Yum! After lunch, I attended Daniel Lindeman’s “Python in Serverless Architectures.” Now I know what the buzzword “serverless” means! I even found out that I had already developed a serverless app using Django and Heroku. There are some really cool ways test automation could take advantage of serverless architectures.

Another one of my favorite talks of the afternoon was Vince Salvino’s “Containers Without the Magic.” Vince broke down how easy containers are to use. It was a great refresher for me.

Open Spaces

At 3:15 on Sunday, I tried something new: I hosted an open space for test automation. “Open spaces” are rooms that can be reserved for a time slot to meet up informally about a common interest. (For example, PyCon had a juggling open space!) At first, nobody showed up to my open space, but after a few minutes, one lady walked in. She had been a software tester for years and wanted to start doing automation. I walked her through as much info as I could before time was up. She was very grateful for the guidance I offered. It worked out nicely that she was the only person to come to my open space so that she could really get value out of it. (My friend Jason also popped in and helped out; more on him below.)

The After-Party

At conferences, my biggest fear is being awkwardly alone. I want to spend time with good people, both new and familiar. Thankfully, PyOhio didn’t disappoint.

Backstory: At PyCon 2018, I met a guy named Julian who runs PyBites (together with his buddy Bob). We really hit it off, and he invited me to join the PyBites community. They offer great code challenges and a “100 Days of Code” challenge course, as well as a blog about all things Python. Through the PyBites community, I met another guy named Jason who would be at PyOhio 2018 with me. We agreed to meet up for dinner and drinks after the Sunday talks.

(On a side note, I recommend PyBites as a great place to learn new things, hone skills, and meet great people!)

That Sunday night, it just so happened that Adrienne and Trey, two of the other speakers, intersected Jason and me as we were deciding where to go for dinner. The next thing we know (after a hotel pitstop), we’re all walking off together to Eden Burger, a local vegan burger joint. I had a vegan “cheeseburger” with fries and a “milkshake” – and they were genuinely delicious! More than the food, I enjoyed my time with new friends. I was really inspired by the cool things each of them is doing. I guess that’s Python conference magic!

Jason and I hit World of Beer after dinner. After Slack-ing for weeks, it was so good to spend time with this fine gent. We discussed Python, software, our careers, our families, and our dreams. What a perfect way to conclude PyOhio 2018!

Takeaways

There were so many takeaways from PyOhio 2018 for me:

  1. Conferences are phenomenal for professional development. The pulse I get from conferences is electrifying. I walked away from PyOhio galvanized to be an even better software engineer. The talks opened up exciting new ideas. Inspiration for several blog posts sprang forward. The people I met motivated me to try new things. I got so much vigor out of such a short time.
  2. My friends around the globe are awesome. Matt, Jason, Adrienne, Trey, Julian (vicariously), and all the other great people I met at PyOhio made my conference experience so rewarding.
  3. Good values foster wonderful communities. My company, PrecisionLender, has four major values: Be helpful, humble, honest, and human. Those values make my company such a great place to work. I see those same values in the Python community, too. People at PyOhio even asked about these values when they saw them on my PL shirt and my business card. I think that’s partially why Python conferences are always so welcoming and inspiring.
  4. Bigger conferences have more pizzazz, while smaller conferences are more intimate. PyCon 2018 was big, flashy, and awesome. I scored so much swag that I nearly couldn’t fit it all in my suitcase to carry home. PyOhio 2018, on the other hand, focused much more intently on the talks and the people. A perfect example of this was Leo Guinan’s monologue-turned-dialogue on Airflow: it was natural for people to just ask questions. Both types of conferences are good in their own ways.
  5. PyCon 2018 was likely a watershed moment for my career. I cannot reflect on PyOhio 2018 without seeing it as an extension of my PyCon 2018 experience. The only reason I attended PyOhio was because someone at PyCon encouraged me to propose a talk. The reason I met Jason is because I first met Julian. The reason I want to keep speaking is because PyCon went so well for me. The fact that both conferences were hosted in Ohio only two months apart is also rather serendipitous. Like my first trip to China, I think PyCon 2018 will have a lasting impact on my career.

EGAD! How Do We Start Writing (Better) Tests?

Some have never automated tests and can’t check themselves before they wreck themselves. Others have 1000s of tests that are flaky, duplicative, and slow. Wa-do-we-do? Well, I gave a talk about this problem at PyOhio 2018 and again at PyGotham 2018. The language used for example code was Python, but the principles apply to any language.

Here’s the PyGotham talk:

And here’s the earlier PyOhio version: