Elegant Automation Frameworks with Python and Pytest

Let's set up Python 3 on your Windows machine, and ensure we're working with the same tools so you don't run into unnecessary hardship.

In order to avoid problems, it's best if you and I are working with the same tools. I want automating to be a fun and rewarding experience, not a frustrating one!

For those of you working on Mac OS or linux, I've got you covered! We go over setting up Python 3 and your virtual environment.

We may not want to run all the tests all the time. It would also be nice if we could organize our tests so that they weren't all crammed into a single folder. In this session we will discuss why test searching is so amazing, and why you should never run a test case file ever again.

Let's go over the core principles of test search...

Fixtures are one of the most powerful tools Pytest offers. I have personally seen a fixture-based approach eliminate 80% of all code from a test suite by eliminating duplicated and copy-paste setup/teardown code. If you need to change or remove something, you do it once and you're done. Think of what you could do with all that time not spent maintaining thousands of lines of duplicated code.

It's important to demonstrate understanding of the foundations of fixtures and some of the use cases where they are very useful

A good automation framework provides on-demand, actionable information about the status of the product. Today we learn how to generate HTML reports for quick, readable summaries, but more importantly how to generate XML reports that can be read by many analysis tools.

I will demonstrate a quick reporting recipe using the open source Continuous Integration tool "Jenkins", since many students may work on teams that use Jenkins. The concept is transferable to many other tools that read XML test reports.

A good test framework is customizable, and we shouldn't be changing test code to accomodate changes. We will learn how to pass data into your test run using the command line, and write a self-building configuration file that allows testing in different environments without changing any code.

How do we skip tests without forgetting we ever wrote them? How do we handle tests that are expected to fail? We cover both of these solutions in today's lecture.

Too often I see copy and pasted test cases in cases where we want to run the same test against multiple sets of data. In this lecture we learn a recipe for testing multiple browsers without writing additional tests, and how to perform Data-driven testing using the contents of a JSON file.

Learn the difference between parallelism and concurrency, and how we can leverage parallel testing to slash run-times on our test suites.

Unit Tests are performed at the lowest levels of the code, often at the level of validating the expected behavior of a single function. We will learn how to write valuable, well-scoped unit tests to expose bugs before we push our changes to the repository.

In order to set up our unit tests for primetime, it's important to separate our testing harness and cases from the library we are testing. We will use a tool called Tox to make this process fast, fluid, and repeatable.

Functional Tests can be at any level of the product, though for our purposes I use the term to mean any testing which occurs external to the product's code. When testing something from the "outside", it's important that we structure our tests and framework so that our intent is clear, and so that the tests are maintainable by other people.