Using Multiple Test Frameworks Simultaneously

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.

Grace Hopper Bug

Writing Good Bug Reports

Bugs, bugs, bugs! Talking about software development is impossible without also talking about bugs. At first, the term “bug” may seem like strange slang for “defect.” Are there creepy-crawlies running about our code and computers? Not usually, sometimes yes! In 1947, Grace Hopper found a dead moth stuck in a relay in Harvard’s Mark II computer, and her “bug” report (pictured above) joked about finding a real bug behind a computer defect. Even though inventors like Thomas Edison had used the term “bug” to describe technological glitches for years beforehand, Grace Hopper’s bug cemented the terminology for computers and software.

Bug happen. Why? Nobody is perfect, and therefore, no software is perfect. Building software of high quality requires good designs to resist bugs, good implementations to avoid bugs, and good feedback to report bugs when they inevitably appear. This article covers best practices for writing good bug reports when they do happen.

What is a bug “report”?

A “bug” is a defect, plain and simple. The term refers specifically to an issue in the software. However, a bug report (or ticket) is a written record detailing the defect. Bug reports are typically written in a project management tool like Jira. The bug and its report are two separate entities. Certainly, undetected bugs can exist in a software product without having associated reports.

When should a bug report be written?

A bug report should be written whenever a new problem that appears to be a defect is discovered. Problems can be discovered during testing activities like automated test runs or exploratory manual testing. They can also be discovered while developing new features. In the worst case, customers will find problems and submit complaints!

However, notice how I used the term “problem” and not “defect.” All problems need solutions, but not all problems are truly defects. Sometimes, the user who reported the problem doesn’t know how a feature should work. Other times, the environment in which the problem occurred is improperly configured. The team member who first discovered the problem or received the customer complaint should initially do a light investigation to make sure the problem looks like a genuine software defect. Initial investigation should be done expediently while context is fresh.

If the problem appears to be a real defect and not a misunderstanding or misconfiguration, then the investigator should search existing bug reports for the same issue. Someone else on the team might have recently discovered the same issue or a similar issue. Bugs also can reappear even after being “fixed.” Adding information to existing reports is typically a better practice than creating duplicative reports.

What if the problem is unclear? Whenever I’m not sure if a problem is a bug or another type of issue, I ask others on my team for their thoughts. I try to ask questions like, “Does this look right? What could cause this behavior? Did I do something incorrectly?” Blindly opening bug reports for every problem is akin to “the boy who cried wolf” – it can desensitize a team to warnings of real, important bugs. Doing just a bit of investigation shows good intentions and, in many cases, spares the team extra work later. Nevertheless, when in doubt, creating a report is better than not creating a report. A little churn from false positives is better than risking real problems.

Why should bug reports be written?

Whenever a real bug is discovered, a team should write a report for it. Simply talking about the bug might seem like an easier, faster approach, especially for smaller teams, but the act of writing a report for the bug is important for the integrity of the software development process. A written record is an artifact that requires resolution:

  • A report provides a feedback loop to developers.
  • A report contains all bug information in a single source.
  • A report can be tracked in a project management tool.
  • A report can be sized and prioritized with development work.
  • A report records work history for the bug.

Bug reports help make bug fixes part of the development process. They bring attention to bugs, and they cannot be ignored or overlooked easily.

What goes into a bug report?

Regardless of tool or team process, good bug reports contain the following information:

  • Problem Summary
    • A brief, one-line description of the defect
    • Clearly states what it defective
    • Should be used as the title of the report
  • Report Identifier
    • A unique identifier for the bug report
    • Typically generated automatically by the management tool (like Jira)
  • Full Description
    • A longer description of the problem
    • Explain any relevant information
    • Use clear, plain language
  • Steps to Reproduce
    • A clear procedure for manually reproducing the failure
    • Could be steps from a failing test case
    • Include actual vs. expected results
  • Occurrences
    • Cases when the defect does and does not appear
    • Share product version, code branch, environment name, system configuration, etc.
    • Does the defect appear consistently or intermittently?
  • Artifacts
    • Attach logs, screenshots, files, links, etc.
  • Impact
    • How does the defect affect the customer?
    • Does the defect block any development work?
    • What test cases will fail due to this defect?
  • Root Cause Analysis
    • If known, explain why the defect happened
    • If unknown, offer possible reasons for the defect
    • Warning: clearly denote proof vs. speculation!
  • Triage
    • Assign an owner if possible
    • Assign a severity or priority based on guidelines and common sense
    • Assign a deadline if applicable
    • Assign any other information the team needs

I use this list as a template whenever I write bug reports. For example, in a Jira bug ticket, I’ll make each item a heading in the ticket’s “Description” field. Sometimes, I might skip sections if I don’t have the information. However, I typically don’t open a bug report until I have most of this information for the defect.

How should bug reports be handled?

One word: professionally. Handle bug reports professionally. What does that mean?

Provide as much information as possible in bug reports. Bug reports are a form of communication and record. Saying little more than, “It dun broke,” doesn’t help anyone fix the problem. Provide useful, accurate information so that others who didn’t discover the bug have enough context to help.

Triage bugs expediently. When you uncover a problem, investigate it. When you need a second opinion, ask for it. When someone sends a bug report to you or your team, triage it, fix it, and reply to the person who reported it. Don’t ignore problems, and don’t let them fester.

Treat bug reports as unfolding stories. Bugs are usually unexpected, tricky surprises. The information in a bug report can be incomplete or even incorrect because it represents best-guess theories about the defect. The report artifact should be treated as a living document. Information can be added or updated as work proceeds. Team members should be gracious to each other regarding available information.

Do not shame or be shamed. Bugs happen. Even the best developers make mistakes. A mature, healthy team should faithfully report bugs, quickly resolve them, and take steps to avoid similar problems in the future. Developers should not stigmatize bugs or try to censor bug counts. Testers should not brag about the number of bugs they find. Language used in bug reports should focus on software, not people. Gossiping and public shaming over bugs should not happen. Any shame associated with bugs can drive a team to do bad practices. Any recurring issues should be addressed with individuals directly or with the help of management.

Good bug reports matter

Writing bug reports well is vital for team collaboration. Organized, accurate information can save hours of time wasted on fruitless attempts to reproduce issues or attempt fixes. Give these practices a try the next time you discover a bug!

PyCon 2020 is Cancelled: Here’s Why It Hurts and What We Can Do

PyCon 2020 was cancelled today due to COVID-19. You can read the official announcement here: https://pycon.blogspot.com/2020/03/pycon-us-2020-in-pittsburgh.html. I completely support the Python Software Foundation in this decision, and I can’t imagine how difficult these past few weeks must have been for them.

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!

PyCarolinas 2020 Update

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.

If you want to help us take the next steps, sign up for our newsletter and join our Slack room. With this new inspiration and energy, I’ll do my best to stay on top of things.

East Meets West When Translating Django Apps

你好!我叫安迪。 

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.

I gave this talk at a few conferences. It was the opener for PyCascades 2020. I also delivered it in person at PyTennessee 2020 and online for PyCon 2020.

Here’s the PyCon recording, which is probably the “definitive” version:

Here’s the PyCascades recording:

Here are the power slides from my talk:

Check out my article, Django Admin Translations, to learn how to translate the admin site, too.

4 Rules for Writing Good Gherkin

In Behavior-Driven Development, Gherkin is a specification language for defining behaviors. Gherkin scenarios can easily be automated into test cases. There are many points to writing good Gherkin, but to keep things simple, I like to focus on four major rules:

  1. Gherkin’s Golden Rule
  2. The Cardinal Rule of BDD
  3. The Unique Example Rule
  4. The Good Grammar Rule

Check out my TechBeacon article to learn about these rules in depth!

How Do I Start Learning Python?

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:

  1. 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.
  2. 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!
  3. 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.

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.

My 2020 Goals

Friends, I know I haven’t published many blog articles recently. I’d like to give a brief update on things in my life, and I’d also like to share my personal goals for 2020.

Personal Life

My life is busy as ever. Unfortunately, I went mostly dark for nearly two months.

Immediately after hosting Thanksgiving, my wife (Jessica) and I took a two-week trip to China. We spent a week in Shanghai and a week in Taipei. Shanghai was frustrating. We missed a flight to visit Jessica’s family in Shandong province. (Apparently, Jessica’s uncle in the CCP didn’t want to see us anyway because visiting an American might cost him a promotion at his company.) Then, we had to run all over the city to take care of bureaucratic paperwork. Taiwan, on the other hand, was awesome. We did many touristy things: Taipei 101, night markets, Jiufen, Shifen, and Beitou. My favorite part was the National Palace Museum, which houses priceless treasures evacuated from the Forbidden City during the Chinese Civil War.

Linjiang Street Night Market in Taipei, Taiwan

During our time in the East, Jessica and I were also under contract to buy a third house. Jessica wants to invest in more real estate and operate more Airbnb listings. Buying a house is never easy. Closing went well after we returned to the States, but we had to do lots of work to prep the house. I installed a new door and fixed an attic access panel. I changed all the plugs, switches, door handles, and door hinges. Jessica handled all the furniture and decorating. We even drove a new IKEA couch from Baltimore to Raleigh on the roof of my car. We also had to shut down the natural gas over New Years due to a pesky leak. Thankfully, the house is now listed on Airbnb.

Baltimore to Raleigh

At the same time, we did major projects at Jessica’s Mama’s house. We installed a new roof and siding – expensive, but needed. At the same time, we replaced two shower valves because they were leaky. We also installed an electric air unit in the upstairs guest suite. Unfortunately, that project was a nightmare. We needed to hack a new breaker into the electrical panel, and then we discovered that the exterior air unit came broken out of the box. Our next projects will be to paint the house and install gutters.

Home improvement projects at Mama’s house

Immediately after Christmas, my dad fell ill. He spent several days in the hospital. Thankfully, he will make a full recovery.

Needless to say, 2020 got off to a rough start.

Company Buyout

In September 2019, Q2, a banking software company located in Austin, Texas, announced that they would buy my company, PrecisionLender. The deal completed on Halloween. Buyouts can be scary, but thankfully, this one seems okay. I still work on the same team for the same projects. Q2 has showered us with swag. We will still receive our annual bonuses. I even get to take a trip to Austin in February to visit the Quality Enablement team there. I plan to stay at Q2.

The First Half of 2020

I want to focus on speaking engagements for the first half of 2020:

  1. Feb 3-5: How to Start Testing with Python at Automation Guild 2020
  2. Feb 8-9: East Meets West When Translating Django Apps at PyCascades 2020
  3. Feb 14: How PrecisionLender Does Testing at Q2
  4. Feb 26-27: Blasting Off with Good Gherkin at TSQA 2020
  5. Mar 7-8: East Meets West When Translating Django Apps at PyTennessee 2020
  6. Mar 11: Beyond Unit Testing: End-to-End Web UI Testing with Women Who Code Python
  7. April 15-16: Hands-On Web App Test Automation (tutorial) at PyCon 2020
  8. April 17-19: East Meets West When Translating Django Apps at PyCon 2020

I might have a few more engagements. I also plan to create two more courses for Test Automation University.

The first half of 2020 will culminate in PyCarolinas 2020. I’ve had a dream to bring a regional Python conference home to the Carolinas. Thanks to many friends in the Python community, PyCarolinas will happen this year. We will host it on June 20-21 at the Red Hat Annex in Raleigh, NC. As a co-chair, I will take charge of the program. I hope PyCarolinas will be a great conference, and it should be a fitting milestone for the first half of my year.

Image
PyCascades 2020 action shot (courtesy of @theavalkyrie)

The Second Half

My big goal for the second half of 2020 is to write a book on software testing and automation. I’ve wanted to write a book for years. Now is the time. I want to write a full treatise on the art of software testing. I will write the book’s companion code in Python because I believe that Python is one of the best languages for test automation.

Writing a book is no small task. I will need to say “no” to many good things in order to do this great thing. I plan to step back from conferences while I work on my book (although I’ll still try to attend some favorites). I won’t teach any courses at Wake Tech as an adjunct professor. I probably won’t write many new blog articles during that time, either.

Let’s Go!

2020 will be a busy year. Please encourage me to stay on track! You can follow me on Twitter at @AutomationPanda to keep up with me.

Automation Guild 2020 selfie

Beyond Unit Tests: End-to-End Web UI Testing

On October 4, 2019, I gave a talk entitled Beyond Unit Tests: End-to-End Web UI Testing at PyGotham 2019. Check it out below! I show how to write a concise-yet-complete test solution for Web UI test cases using Python, pytest, and Selenium WebDriver.

This talk is a condensed version of my Hands-On Web UI Testing tutorials that I delivered at DjangoCon 2019 and PyOhio 2019. If you’d like to take the full tutorial, check out https://github.com/AndyLPK247/djangocon-2019-web-ui-testing. Full instructions are in the README.

Be sure to check out the other PyGotham 2019 talks, too. My favorite was Dungeons & Dragons & Python: Epic Adventures with Prompt-Toolkit and Friends by Mike Pirnat.

Python Program Main Function

This article will show you the best way to handle “main” functions in Python.

Python is like a scripting language in that all lines in a Python “module” (a .py file) are executed whenever the file is run. Modules don’t need a “main” function. Consider a module named stuff.py with the following code:

def print_stuff():
  print("stuff happened!")

print_stuff()

This is the output when it is run:

$ python stuff.py
stuff happened!

The print_stuff function was called as a regular line of code, not in any function. When the module ran, this line was executed.

This will cause a problem, though, if stuff is imported by another module. Consider a second module named more_stuff.py:

import stuff

stuff.print_stuff()
print("more stuff!")

At first glance, we may expect to see two lines printed. However, running more_stuff actually prints three lines:

$ python more_stuff.py
stuff happened!
stuff happened!
more stuff!

Why did “stuff happened!” get printed twice? Well, when “import stuff” was called, the stuff module was loaded. Whenever a module is loaded, all of its code is executed. The print_stuff function was called at line 4 in the stuff module. Then, it was called again at line 3 in the more_stuff module.

So, how can we avoid this problem? Simple: check the module’s __name__. The __name__ variable (pronounced “dunder name”) is dynamically set to the module’s name. If the module is the main entry point, then __name__ will be set to “__main__”. Otherwise, if the module is simply imported, then it will be set to the module’s filename without the “.py” extension.

Let’s rewrite our modules. Here’s stuff:

def print_stuff():
  print("stuff happened!")

if __name__ == '__main__':
  print_stuff()

And here’s more_stuff:

import stuff

if __name__ == '__main__':
  stuff.print_stuff()
  print("more stuff!")

If we rerun more_stuff, then the line “stuff happened!” will print only once:

$ python more_stuff.py
stuff happened!
more stuff!

As a best programming practice, Python modules should not contain any directly-called lines. They should contain only functions, classes, and variable initializations. Anything to be executed as a “main” body should be done after a check for “if __name__ == ‘__main__'”. That way, no rogue calls are made when modules are imported by other modules. The conditional check for __name__ also makes the “main” body clear to the reader.

Some people still like to have a “main” function. That’s cool. Just do it like this:

import stuff

def main():
  stuff.print_stuff()
  print("more stuff!")

if __name__ == '__main__':
  main()

For more information, read this Stack Overflow article:
What does if __name__ == “__main__”: do?