You’ve been grinding through tutorials. You've built a portfolio site, maybe deployed a few projects on GitHub. And now you're trying to land a job or join a team.

Then the interviews start.

Suddenly, people ask:

• "Are you familiar with Agile?"

• "Have you worked in a Scrum environment?"

• "What’s your experience with sprints?"

Cue the imposter syndrome. Because no one teaches this stuff in JavaScript 101.

This guide is for you.

I’ll help make the Scrum process – a very common way developers work together – make actual sense. I’ll walk you through the basics, but also tell you what developers actually do, how standups feel when you're new, and what’s expected of you when you’re no longer coding in a vacuum.

Let’s break it down.

Here’s what we’ll cover:

• What Even Is Scrum?

• The Three Roles in Scrum (and Who Does What)

• The Scrum Rhythm: What a Sprint Actually Looks Like

• Who attends the Ceremonies:

• Standups: Where You Talk Like a Human, Not a Robot

• Sprint Planning

• What’s a User Story and Why Does It Sound Like a Children’s Book?

• What Counts as “Done”? Definition of Done and Why It’s Important

• Demos, Retros, and Saying the Hard Things

• Tools You Might Encounter

• If You’re Preparing for a Job, Here’s What You Can Do

• Final Thoughts

What Even Is Scrum?

Scrum is not a tool. It’s not a software. It’s not some elite thing only PMs care about.

It’s a lightweight framework that helps software teams build things incrementally, together, in short focused cycles called sprints.

Scrum is used by everyone from FAANG teams to indie dev shops because it helps:

• Keep teams aligned

• Deliver working software fast

• Course-correct often

• Spot problems early (before they go nuclear)

It’s the opposite of the old-school “build for a year and pray it works” model.

The Three Roles in Scrum (and Who Does What)

Scrum officially defines three roles. Here's what that means in practice:

1. Product Owner (PO)

Think: Vision-holder. They decide what the team builds and why. A product owner:

• Writes user stories (think of these as feature requests written from a user’s point of view)

• Prioritizes the work

• Clarifies what success looks like

• Says “yes” or “not yet” to features

2. Scrum Master (SM)

Think: Air-traffic controller meets therapist. They make sure the process works. The are master Facilitators, like between Dev and PO’s. A Scrum Master:

• Facilitates meetings

• Removes blockers (“Your AWS access is stuck? I’ll escalate it.”)

• Coaches the team on Scrum practices

• Doesn’t manage people – manages flow

3. Developers (YOU!)

Think: Builders. You write code, test it, ship it, fix it, and improve it. You also:

• Break down stories into tasks

• Pick up work from the team board (like Jira or Trello)

• Communicate progress

• Demo what you’ve built at the end of the sprint

You might also work with designers, testers, or DevOps folks – but within Scrum, you’re all “developers” building a product together.

The Scrum Rhythm: What a Sprint Actually Looks Like

Image Source: https://www.invensislearning.com/blog/what-are-scrum-ceremonies/

Understanding the Scrum Cycle

So, what does it actually look like when a team uses Scrum to build software?

Let’s walk through a full sprint – not just the buzzwords, but what really happens when a group of humans tries to plan, build, review, and improve together. Think of this as your backstage pass to the rhythm of modern teamwork.

📦 Step 1: Build and Refine the Product Backlog

Before any coding starts, the team needs to agree on what they might build – not just this week, but in the near future too.

That’s where the Product Backlog comes in. This is a big, running list of everything the product might need – features, bug fixes, improvements, ideas, and maybe a few wild dreams. It’s like the wishlist for the product, but more organized (ideally).

The Product Owner is responsible for maintaining and prioritizing this list. They decide what’s most important to work on based on customer needs, business goals, and feedback.

But the PO doesn’t do this in isolation. Enter the Backlog Refinement meeting.

In these sessions, the Scrum Team – that’s the PO, the Scrum Master (SM), and the Developers – come together to:

• Review the most important upcoming items

• Clarify any vague or confusing parts of each task

• Break big items down into smaller, buildable pieces called user stories

• Estimate effort (how much time or complexity is involved for each story)

This meeting makes sure the team isn’t caught off guard in the sprint – that they understand the work ahead and can actually start sprinting when the time comes.

🧭 Step 2: Sprint Planning – What Are We Building This Time?

Now that we’ve got a solid backlog, it’s time to pick what to build right now.

At the start of each sprint (which typically lasts 1 to 4 weeks), the team holds a Sprint Planning meeting. This meeting sets the stage for the entire sprint – it’s like the huddle before the big game.

In Sprint Planning, the team:

• Reviews the top items from the backlog

• Discusses what can realistically be completed based on their availability and capacity

• Chooses a handful of these stories to commit to

• Defines a Sprint Goal – a simple statement that captures the purpose of this sprint

For example, the Sprint Goal might be:
🎯 “Allow users to reset their passwords.”

Every user story chosen should contribute to that goal. The collection of these stories becomes the Sprint Backlog – basically, the to-do list for the sprint.

So when we say:

“The team selects an ordered list of user stories to comprise the Sprint Backlog for the next sprint, which will be achievable to satisfy the Sprint Goal...”

We’re really just saying:
👉 “Pick a realistic number of important tasks that, if completed, will help us hit our target for the sprint.”

Not too vague. Not too ambitious. Just achievable and focused.

☀️ Step 3: Daily Standups – Stay in Sync

Now the sprint is underway! But how does everyone stay aligned and avoid working in silos?

That’s where the Daily Standup comes in. Every day – usually in the morning – the team has a quick check-in (about 15 minutes) where each person answers three questions:

1. What did I do yesterday?

2. What am I working on today?

3. Is anything blocking me? (that is, am I stuck?)

Example:

“Yesterday I set up the login API integration. Today I’ll work on the UI validation. I’m blocked on getting access to the staging database — may need help.”

These standups keep the team in sync and surface blockers early so they can be addressed quickly. They’re not about micromanaging or showing off. They’re about visibility and support.

📉 What’s a Sprint Burndown Chart?

You might hear your team mention a “burndown chart.” No, this isn’t about things going down in flames (hopefully).

A Sprint Burndown Chart is a graph that shows how much work is left in the sprint – day by day.

• The y-axis is the amount of work remaining (often measured in story points or tasks)

• The x-axis is the number of days left in the sprint

The line should ideally trend downward as work gets completed – hence “burning down.” If it flattens out or slopes up, that’s a red flag that the team might be stuck, behind schedule, or not updating the board.

Think of it as a visual heartbeat of the sprint. You can learn more via a practical example in this video.

🖥️ Step 4: Sprint Review – Show What You’ve Built

At the end of the sprint, the team holds a Sprint Review (also called a “demo”). This is where you show what was actually built during the sprint.

• The Developers demo working features – live, not just screenshots

• The Product Owner reviews whether the Sprint Goal was achieved

• Stakeholders may ask questions, give feedback, or suggest tweaks

This meeting isn’t just for show – it’s a feedback loop. It helps the team validate that what they built is useful, usable, and meets expectations. If changes are needed, those get added to the backlog for future sprints.

🔍 Step 5: Sprint Retrospective – Look Back to Move Forward

Once the review is done, the team shifts focus from what they built to how they worked together.

Enter the Sprint Retrospective – a meeting to reflect on the process, not the product.

The team discusses:

• ✅ What went well

• ❌ What didn’t go so well

• 🔁 What could be improved next time

This isn’t about pointing fingers. It’s about learning, adapting, and continuously improving how the team collaborates.

The Scrum Master often facilitates this meeting and helps turn feedback into action items for the next sprint. For example:

“We underestimated testing time. Next sprint, let’s budget for QA earlier.”

The best teams take retros seriously. Why? Because even if your code is perfect, your process needs tuning too – and small process changes often lead to big gains.

♻️ Scrum Is a Loop

Here’s the rhythm:

1. Plan the sprint

2. Check in daily

3. Build and demo the product

4. Reflect and improve

Then do it all over again – with slightly better coordination and slightly more trust each time.

It’s not about being fast. It’s about being intentional, consistent, and collaborative.

Example Sprint

Let’s say, for example, that your team does 4-week sprints. (Keep in mind that Sprints can differ by team, nature of product, release cycles, and so on.)

Here’s the rough beat:

Scrum works in loops. Every 2-4 weeks (depending on your cadence and sprint cycle), your team should have working, demo-able software to show for it – even if it’s small.

And no, it’s not about “speed.” It’s about consistency, communication, and collaboration.

Who attends the Ceremonies:

Now lets dive deeper and understand practically how each of these ceremonies work:

Standups: Where You Talk Like a Human, Not a Robot

So how does the team actually stay connected day to day? That’s where standups come in.

Every morning, your team meets briefly – usually on Zoom or in a circle – and you answer 3 questions:

1. What did I work on yesterday?

2. What will I work on today?

3. What’s blocking me? Any impediments?

Example:

"Yesterday I cleaned up the signup validation logic. Today I’m working on the email verification flow. I’m stuck on SendGrid config – might need help setting up credentials."

It’s not about impressing anyone. It’s about keeping everyone in sync. Some days you’ll say, “I spent the whole day debugging a CSS bug that turned out to be a semicolon.” That’s okay.

How does it work?

The Scrum Master gathers everyone in a huddle room, the PO and Dev Team included, and opens the the Standup. They are the facilitator of the ceremony. Everyone gets a chance to answer the 3 questions above (usually about 2-5 minutes each). It’s not a full report – it’s quick. When one person is done, they pass it on to someone else.

This ensures there is team cohesion and transparency.

Here is a video example of a standup.

Sprint Planning

The goal of the planning meeting is to answer the questions “What are we going to work on, and how are we going to do it?” It is critical for the team to have a shared goal and a shared commitment to this goal before beginning this ceremony.

Participants should:

• Measure growth

• Sync with the Scrum Master

• Sync with the Product Owner

Sprint planning happens just before the sprint starts, and usually lasts for an hour or two. In this meeting, the team goes over a collection of user stories and discuss, plan, measure, and prioritize. This is where they decide what is going to be in scope for their upcoming sprint cycle.

The Product Owner will have a prioritized view of things in the backlog. They work with the team on each object or customer experience. Together, as a group they go through and make calculations, deciding to what they can commit.

What’s a User Story and Why Does It Sound Like a Children’s Book?

So you might be wondering: how do you know what to work on? What to build? So much work, so little time? Thats where user stories come in.

In Scrum, teams don’t just write vague tasks like “code the login.” Instead, they write user stories – short, human-centered feature descriptions that describe what the user needs, why they need it, and what success looks like.

Here’s an example:

As a user, I want to be able to reset my password, so I can access my account if I forget it.

User stories are the scaffolding of teamwork. They’re written with empathy, not just efficiency. And each one comes with acceptance criteria – a checklist that clarifies what “done” actually means:

• A “Forgot Password” link is visible

• Clicking it shows a form

• An email gets sent with a reset link

Once a story is agreed upon, developers break it down into tasks, like “build form,” “hook into backend,” or “handle email validation.” It’s collaborative, not prescriptive. And user stories have priority so you know what’s the most important and what’s the least.

A helpful rule of thumb many teams use is the Gherkin-style "Given–When–Then" format:

• Given some initial context

• When an event occurs

• Then a specific outcome should happen

This ensures that everyone – devs, testers, and product owners – shares the same understanding of behavior and expectations.

Here is a great video example thats outlines how to draft effective and powerful user stories.

What Counts as “Done”? Definition of Done and Why It’s Important

Now you might be wondering – how do I know when a task is done and can be closed out?

The Definition of Done is a type of documentation in the form of a team agreement. The Definition of Done identifies the conditions that need to be achieved in order for the product to be considered done (as in potentially shippable).

This is how we know that we "did the thing right". Meaning, we built the correct level of quality into the product. The Definition of Done is not the same as the acceptance criteria, which are written by the product owner to help us know we did the "right thing".

Every team has a Definition of Done – it’s not just “I pushed code.” It could mean:

• Code is written

• Reviewed by a peer

• Merged into main

• Tested on staging

• Possibly deployed

This clarity keeps teams honest and accountable. No “it works on my machine” energy here. The DoD sets a quality bar. It prevents ambiguity, rework, and “it works on my machine” moments. When every card on the board passes the same finish line, teams move faster – and trust each other more.

Everyone should know what done is in a team. Either its Done as per DoD standards or its not.

Here is a beautiful video highlighting the impotence of DoD.

Demos, Retros, and Saying the Hard Things

Once you’ve built the product, then comes demos (showcasing your work) and retros (analysis as a team on what when well and what areas to improve on).

In the retro, everyone’s encouraged to speak up:

• What went well?

• What didn’t?

• What should we try next time?

Example:

“We missed a lot of stories because we didn’t account for testing time. Maybe we buffer next sprint with fewer tasks.”

The goal is not to blame – it’s to improve. Over time, this feedback loop becomes gold. The Scrum Master usually facilitates, collects feedback (via tools like Parabol, Miro, or sticky notes), and helps turn insights into actionable experiments for the next sprint.

Over time, retros become the heartbeat of team evolution.

Here is a video highlighting the importance of a Retro and Sprint Review.

🧠 Why Retrospection Matters More Than You Think

The Sprint Retrospective is more than just another meeting. It’s a mirror for your team – a safe, structured space to pause, reflect, and improve together.

You discuss:

✅ what went well

❌ what did not go well

🔁 what could we do better next time

Great teams don't just deliver great software, they continually deliver better ways of working.

This is why many experienced Scrum practitioners consider the retro to be the most important event in Scrum. Code is deployed once, but process improvements grow exponentially, sprint after sprint.

Tools You Might Encounter

Scrum doesn’t require software, but real-world teams use a variety of tools:

• Jira – Tracks sprints, issues, velocity

• Trello – Simple board, good for small teams

• Slack – Where standups often happen if async

• Notion / Confluence – Docs, retros, notes

• GitHub Projects – Lightweight planning for devs

Don’t worry if you’re not fluent in these yet. They’re tools – you’ll learn them on the job.

If You’re Preparing for a Job, Here’s What You Can Do

• ✍️ Practice writing user stories from your side projects

• 🧪 Run a mini-sprint: Plan your weekend project, set goals, and “review” it at the end

• 🤝 Contribute to an open-source project that uses Scrum or Agile workflows

• 🧾 Write about what you learned – maybe as a tutorial (hint hint)

Final Thoughts

So to recap, Scrum is a simple yet powerful way for teams to work together, stay organized, and deliver results quickly. It runs in short cycles called sprints, where the team plans what to do, checks in daily, shows their progress at the end, and reflects on how to improve.

The four key ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective – help keep everyone aligned and focused. With clear roles and regular feedback, Scrum makes it easier to handle changes, solve problems early, and continuously get better as a team.

But scrum isn’t a magic spell. It’s just a way for humans to build complex things – together – without falling apart.

You don’t need to be a Scrum Master. You don’t need a certification. But if you understand how sprints work, what’s expected of you, and how to show up to meetings with clarity and candor, you’re 10 steps ahead of most.

Scrum helps teams talk, plan, build, and learn. And now? You can too.

If you liked this, please do share. You never know who it might help out.

Until then…keep learning, unlearning, and relearning!!!

While this brings an increase in productivity, there's a growing downside. AI-generated code is prone to errors, unexpected bugs, or poor integration with the rest of your code.

Because of these risks, it’s more important than ever to establish robust testing practices to make sure your code is high quality and properly functioning. Various testing tools are available to help solve these challenges, and pytest stands out in the Python ecosystem for its simplicity, flexibility, and powerful features.

In this article, we'll explore the following topics:

Table of Contents

• Why Use pytest?

• How to Write Your First Tests with pytest

• How to Run pytest Tests

• How to Interpret pytest Results

• How to Handle Exceptions in pytest

• Advanced pytest Features

  • 1. pytest Markers

  • 2. pytest Fixtures

  • 3. Parametrization

  • 4. pytest Plugins

• Conclusion

By the end of this article, you will have a comprehensive knowledge of pytest and be able to use it in your Python development process.

Pre-requisites

• Must have Python installed

• An understanding of the Python programming language

Why Use pytest?

pytest is a popular testing framework for Python that makes it easy to write and run tests. Unlike unittest and other Python testing frameworks, pytest’s simple syntax allows developers to write tests directly as functions or within classes. This lets you write clean, readable code without complexities.

pytest also supports popular Python frameworks like Flask, Django, and more. Combined with other rich features, pytest equips you with the tools you need to ship reliable software in today’s AI-driven era.

Key features of pytest that make it a preferred testing tool include:

• Flexibility: it provides flexibility in test structure by supporting tests for functions, classes, and modules.

• Detailed test output: it provides a detailed and readable test output, making it easy to understand test failures and errors.

• Automatic test discovery: it automatically discovers tests by looking for files that start with "test_" or end with "_test.py". This eliminates the need for manually specifying test files**.**

• Parameterization: it supports parameterized tests, which allow you to run a single test function with multiple sets of inputs.

• Fixtures: it fixtures provide setup and tearDown methods that help prevent code repetition. This enables you to set up baseline conditions for your tests and also delete them after each test.

• Plugins and extensions: it has a rich ecosystem of plugins and extensions that add extra functionalities, such as detailed tests reporting, and integration with other tools and Python frameworks like Django and Flask.

• Compatibility: it is compatible with other testing frameworks like unittest , allowing you to migrate tests from different testing frameworks and run them seamlessly on it.

How to Write Your First Tests with pytest

This section will guide you through writing your first set of tests using the pytest framework.

pytest is a Python package, and you’ll need to install it before using it. You can do that with the following command:

pip install pytest

NOTE: Following Python's best practices, it’s recommended you install pytest within a virtual environment. Here's a guide to help you set it up.

Next, create a Python file where you will write your tests and import pytest into it using:

import pytest

pytest has 2 basic methods of writing tests, which include:

• The function-based method: This method is straightforward for writing tests because you write the tests in individual functions.

  Note: Each function name must be prefixed with the word test_ for pytest to discover and run these tests automatically.

  Here’s an example of a function-based test:

    def test_addition():
        assert 1 + 1 == 2
  

  Note: In the code above, the assert statement used here in pytest is Python’s built-in “assert”. It’s more convenient and doesn’t require the specific methods like assertEqual and assertTrue which are common with unittest. Another advantage of using the assert statement is that it provides more detailed error messages when an assertion fails.

• Class-based method: This method is similar to the way of writing tests in unittest, except that your test class does not inherit any methods. An example is shown below:

    class TestMathOperations:
        def test_addition(self):
            assert 1 + 1 == 2
  

  This method of writing tests in pytest is useful when you want to group related tests together.

How to Run pytest Tests

Running pytest differs slightly from the normal convention of running regular Python scripts.

The general method of running pytest tests is by running the pytest command in your terminal. pytest will automatically look for and run all files of the form test_*.py or *_test.py in the current directory and subdirectories. But while this may be a great way to run tests, pytest offers more flexibility beyond this general method of running tests.

Depending on preferences, you may want to run your test files based on the following:

1. To run a specific test file: To run tests in a specific file, use the pytest command followed by the file name. For example: pytest test_example.py.

2. To run tests in a directory: Let’s say you have a directory named Tests that contains some test files. To run all the tests in that directory, use the pytest command followed by the directory and a forward slash. For example: pytest Tests/.

3. To run tests using specific keywords: To run tests based on a certain keyword, use the command pytest -k "keyword". Pytest will automatically look for and run function names, class names, or file names matching that keyword in the current directory and subdirectories. But to run tests matching a certain keyword in a specific file, you’d have to specify the file name after the pytest command. For example: pytest test_example.py -k "keyword".

4. Run a specific test within a test file: To run only a specific test inside a test file, use the command pytest test_example.py::test_addition. This will run only the test_addition test function within the test_example.py module.

5. To run all test methods in a specific class: To run all the tests within a specific class, use pytest test_example.py::TestClass. This command would run all the test methods inside the TestClass class in the test_example.py module.

6. To run a specific test method inside a specific class: To run a specific test inside a specific class, use pytest test_example.py::TestClass::test_addition. This command would run the specific test_addition method within the TestClass class in the test_example.py module.

How to Interpret pytest Results

One major advantage pytest has over other Python testing frameworks is the rich output it provides, which gives very detailed information about the status of your tests.

Let’s use a basic test to understand how to interpret pytest’s output:

import pytest

def test_addition():
    assert 1 + 1 == 3

Run this test, and we get an output similar to the one below:

============================== test session starts ====================================
platform win32 -- Python 3.10.5, pytest-8.4.1, pluggy-1.6.0
rootdir: C:\\Users\\hp\\Desktop\\Pytest
collected 1 items

                                                                                  [ 50%]
test_example.py F                                                                 [100%]

===================================== FAILURES =========================================
____________________________________test_addition ______________________________________

    def test_addition():
>       assert 1 + 1 == 3
E       assert (1 + 1) == 3

test_example.py:4: AssertionError
============================== short test summary info =================================
FAILED test_example.py::test_addition - assert (1 + 1) == 3
========================= 1 failed, 1 passed in 0.13s ==================================

The above output is divided into several sections. Here’s a breakdown of what each section means:

1. Test session information:

    =============================== test session starts ===============================
    platform win32 -- Python 3.10.5, pytest-8.4.1, pluggy-1.6.0
    rootdir: C:\\Users\\hp\\Desktop\\TDD pytest
    collected 1 item
   

   • This section displays a summary of the test environment. It begins with a line marker that indicates the beginning of the test session.

   • Below the marker, pytest displays information about the operating system, along with the installed versions of Python, pytest and pluggy. (Pluggy is a pytest dependency used to manage plugins.)

   • The next line indicates the root directory where the test is being run.

   • The last line in this section displays the number of tests found in this directory.

2. Test status:

    test_example.py F                                                              [100%]
   
    ================================== FAILURES =========================================
    ________________________________ test_addition ______________________________________
   
        def test_addition():
    >       assert 1 + 1 == 3
    E       assert (1 + 1) == 3
   
    test_example.py:4: AssertionError
   

   • This section displays information about the status of our tests

   • The first line in this section specifies the test file which is being run, followed by the status (F in this case, which indicates a test failure).

   • The next set of lines gives specific information about the failed tests. This includes the function where the failure occurred (test_addition), and the exact line of code responsible for the error.

   • The last line gives a concise summary of this section. It indicates that the error occurred in test_example.py on line 4 and it was an AssertionError.

3. Test summary:

    ============================= short test summary info =============================
    FAILED test_example.py::test_addition - assert (1 + 1) == 3
    ================================ 1 failed in 0.13s ================================
   

   • This section provides an overall summary of the test.

   • It indicates that the failed test occurred in test_example.py file in the test_addition function because of an incorrect assertion (1 + 1) == 3 which isn’t true.

Edit the code with the correct assertion assert(1 + 1) == 2 and rerun the code. This time, the code passes with a different output.

=============================== test session starts ==================================
platform win32 -- Python 3.10.5, pytest-8.3.2, pluggy-1.5.0
rootdir: C:\\Users\\hp\\Desktop\\TDD pytest
collected 1 items

test_example.py .                                                               [100%]

=============================== 1 passed in 0.01s =================================

How to Handle Exceptions in pytest

Exceptions are unexpected errors that occur while running our tests, and they prevent our code from performing as expected. As a result, pytest offers several built-in mechanisms for handling these exceptions (but we’ll just cover one of them in this article).

pytest.raises Context Manager is a tool that checks if your code raises specific exceptions. If the specified exception is raised, that test passes, confirming that the expected error occurred. But if the specified exception is not raised, that test fails.

Usage Examples of pytest.raises

1. Checking for ValueError: In Python, a ValueError is raised when a function receives an argument with an incorrect value. In the example below, we can verify that a ValueError is raised when attempting to calculate the square root of a negative number.

    import pytest
    import math
   
    def calculate_square_root(value):
        if value < 0:
            raise ValueError("Cannot calculate the square root of a negative number")
        return math.sqrt(value)
   
    def test_calculate_square_root():
        with pytest.raises(ValueError):
            calculate_square_root(-1)
   

2. Checking for ZeroDivisionError: Dividing a number by zero raises a ZeroDivisionError. In this example, we check that this error is raised when dividing a number by zero.

    import pytest
   
    def divide_numbers(numerator, denominator):
        return numerator / denominator
   
    def test_divide_numbers():
        with pytest.raises(ZeroDivisionError):
            divide_numbers(10, 0)
   

3. Checking for TypeError: A TypeError is raised when an operation is applied to an object of an inappropriate type. Here, we check that this error is raised when adding incompatible data types, such as a string and an integer given in the example.

    import pytest
   
    def add_numbers(a, b):
        return a + b
   
    def test_add_numbers():
        with pytest.raises(TypeError):
            add_numbers("10", 5)
   

4. Checking for KeyError: A KeyError is raised when we try to access a dictionary key that doesn’t exist. We can verify and handle this error using the following code:

    import pytest
   
    def get_value(dictionary, key):
        return dictionary[key]
   
    def test_get_value():
        with pytest.raises(KeyError):
            get_value({"name": "Alice"}, "age")
   

Advanced pytest Features

As a robust testing framework, pytest offers some advanced features that help you manage complex test scenarios. In this section, we will explore some of these advanced features at a beginner-friendly level and demonstrate how you can start applying them in your tests.

1. pytest Markers

When working with a large codebase, sometimes running every single test can be time-consuming. This is where pytest markers come in handy.

A marker is just like a label that you can attach to a test function to categorise it. Once a test is labelled, you can instruct pytest to run only tests with certain markers. For example, you may label some tests as "slow" if they take longer to execute and run them separately from the faster ones.

One advantage to using Markers is that it allows you to run specific tests based on categories or specific parameters, and also skip tests if certain conditions aren’t met.

pytest comes along with some built-in markers that can be quite useful:

1. @pytest.mark.skip: This marker allows you to skip a test unconditionally, and can be useful when you know a test will fail due to an external issue or incomplete code.

   Example:

    @pytest.mark.skip(reason="Feature not yet implemented")
    def test_feature():
        pass
   

2. @pytest.mark.skipif: This marker allows you to skip a test conditionally if certain conditions are met.

   Example:

    import sys
   
    @pytest.mark.skipif(sys.platform == "win32", reason="does not run on windows")
    class TestClass:
        def test_function(self):
            "This test will not run under 'win32' platform"
   

3. @pytest.mark.xfail: This marker is attached to tests that are expected to fail, probably due to a bug or incomplete feature. So when pytest runs such tests, it won’t count it as a failure.

   Example:

    @pytest.mark.xfail(reason="division by zero not handled yet")
    def test_divide_by_zero():
        assert divide(10, 0) == 0
   

   Note: Detailed information about skipped/failed tests is not shown by default to avoid cluttering the output.

While pytest comes along with some built-in markers, you can also create your own custom marker (but we won’t cover that in this tutorial). Kindly refer to the documentation for more information on working with custom markers

2. pytest Fixtures

In pytest, fixtures allow you to create reusable default data that can be shared across multiple tests. By using fixtures, you can reduce code repetition, making your tests cleaner and more maintainable.

In pytest, fixtures are defined with the @pytest.fixture decorator as shown in the example below:

Let’s say we have several tests that rely on a list of user data. Instead of repeating the same data in each test, we can create a fixture to hold this data, and the fixture is passed across the tests that need it.

import pytest

@pytest.fixture
def user_data():
    return [
        {"name": "Alice", "age": 30},
        {"name": "Bob", "age": 25},
        {"name": "Charlie", "age": 35}
    ]

# Test function to check for a specific user by name and age
def test_user_exists(user_data):
    user = {"name": "Alice", "age": 30}

    # Check if the target user is in the list
    assert user in user_data

# Test average age of users
def test_average_age(user_data):
    ages = [user["age"] for user in user_data]
    avg_age = sum(ages) / len(ages)
    assert avg_age == 30

Note: The @pytest.fixture decorator in the code above marks the user_data function as a fixture in pytest. This fixture provides reusable data that can be shared across multiple test functions, allowing them to share the same setup without repeating code.

3. Parametrization

Parametrization is a pytest feature that allows you to run a test function with different sets of data at once.

For example: Let’s say you have a function that calculates the square of a number. To provide enough coverage while testing, you would want to test the function with zero, positive, and negative numbers.

Instead of writing separate test functions for each scenario, you can use parametrization to run a test function with different sets of data at once. This approach is more concise, and reduces code duplication.

To use parametrization in pytest, we use the @pytest.mark.parametrize decorator as shown in the example below:

import pytest

# Function to calculate the square of a number
def square_numbers(num):
    return num * num

#Parametrize decorator to test the square function with different inputs
@pytest.mark.parametrize("input_value, expected_output", [
    (2, 4),     
    (-3, 9),    
    (0, 0)    
])

def test_square(input_value, expected_output):
    assert square_numbers(input_value) == expected_output

In the example above, the different input values and expected values are listed in the @pytest.mark.parametrize decorator. We’re testing the square_numbers() function with three different input values: 2, -3, and 0.

For each value, pytest calls the test_square() function and compares the result of square_numbers(input_value) to expected_output.

This approach is more efficient and ensures the function behaves as expected across a variety of cases.

4. pytest Plugins

Plugins are an extension mechanism that allows you to add new functionality to pytest or modify its existing behaviour. These plugins work by providing additional features that extend pytest’s capabilities, which can be useful, especially in complex test scenarios.

pytest has a vast ecosystem of plugins, each designed to suit your different testing needs. You can find the full list of available plugins on PyPI in the pytest Plugin List.

To use a plugin, simply install it with pip.

For example:

pip install pytest-NAME
pip uninstall pytest-NAME

Note: NAME in the code above should be replaced with the name of the plugin you want to install.

After installing a plugin, pytest automatically finds and integrates it. There’s no need for any additional configuration.

In this section, we explored some of pytest's advanced features. By leveraging these features, you can now significantly improve the quality of your tests by ensuring they’re more efficient, scalable, and easier to maintain over time.

Conclusion

In this article, you’ve learned the basics of testing with pytest, from writing and interpreting tests to handling exceptions and using advanced features like fixtures and parametrization.

Whether your code is written manually or generated by AI, learning how to write tests empowers you to detect bugs early, and build more reliable software. Testing acts as a safety net that boosts you confidence during development and ensures your code works as expected.

If you're ready to go a step further, I’ve written an in-depth article on Test Driven Development in Python. It is a powerful approach where writing tests guides your entire coding process.

If you found this helpful, let me know, share it with your network, or give it a like to help others discover it too.