DEV Community: Liz

The time I screwed up a conference talk (And the talk on Pydantic I would have given)

Liz — Sun, 04 Oct 2026 23:00:51 +0000

Hi there -- I know it's been a while. A lot of things have changed and a lot of things have remained the same. I felt inspired to write today for a couple of reasons:

I want to talk about screwing up because I screwed up yesterday and rather than let the shame beat me up, I want to transform these feelings into humility and maybe a lesson you can learn from or relate to
I want to find a way to share my talk because it's a good talk and I am proud of it and you might find some of it useful

Speaking at PyBay

PyBay is one of my favorite conferences. I've spoken at PyBay three times, and each time, I've grown closer to the community. The Python community in the Bay Area is one of the most intelligent, most approachable, and most generous groups of people I've ever had the honor to know. Last year my talk was accepted as an alternate (that I ended up giving) and this year I was accepted as a primary speaker. I was thrilled. I was thrilled to give my talk and be in community. I had proposed an expanded version of a talk I'd given before at smaller meetups, so I was excited to iterate on my content and dive deeper into the subject of Pydantic.

Sometimes you just mess up

I have a lot going on right now. I don't know how it happened, but in addition to professional commitments, I've found myself in leadership positions with my extracurriculars. Art building, community organizing, possibly adopting a new dog ... everything has landed within the months of October and November.

But I had already given versions of the talk in June, so I wasn't making anything from scratch. I've spoken at PyBay before, so everything was familiar. I built out my slide deck, created a Jupyter notebook of code examples, and rehearsed, rehearsed, rehearsed. I curated an immaculate checklist of items to bring with me developed from years of conference experience, wrote out a detailed Trello card with addresses, directions, and attachments. I was ready to be at the venue an hour before my talk so I could settle in and catch one of the other speakers. I was the most prepared I have ever been for a talk ...

... except for one email that I somehow missed in all my checks and rechecks. An email reminding speakers to check in two hours prior to our scheduled talk times or else our slot would be given to an alternate. I arrived anxious but excited and proceeded to the speaker check-in table.

"Oh, we gave your slot to an alternate. You were supposed to be here at 1:30. There was an email."

My heart dropped. "But I ... "

I scrolled through my email. And sure enough, the subject line bolded to indicate it was unread, was the message from three days prior. I read it there, at the speaker check in table, the heat of shame and embarrassment rising up in me.

"I'm sorry -- we've just had issues in the past and we wanted to address that."

"No, no, I get it," I managed to utter. "I understand."

Fortunately, I was not alone. A friend was with me. We walked outside so I could take a breath. The conference organizer noticed me and rushed over, hugging me.

"I'm so sorry," she said. "We tried to call you. We know this isn't like you. We were worried something had happened. And we needed to implement this policy and it wouldn't be fair otherwise." Her eyes were sincere.

I checked my phone again and saw the missed call. My phone had never rang -- we had been crossing the Bay Bridge into San Francisco, where signal can be unreliable.

I've organized events before. Executing an event like PyBay requires precise coordination, contingency plans, and difficult decisions. Last year, I was accepted as an alternate and after a speaker had to drop, I got the opportunity to give my talk.

"That makes sense," I said, meaning it, trying to balance the overwhelming swell of my disappointment against the warm depth of my empathy and understanding against the hot heat of my shame and regret. "I understand."

She offered some more comforting words and hugged me again, and made sure I got a conference t-shirt. There's a reason why she's such a beloved member of the community.

Failing gracefully

In engineering, we talk a lot about graceful failures -- how to handle stuff that goes wrong without breaking the system. I wanted to leave. I wanted to hide in the shadows of shame and regret and be alone with my rumination, pointlessly saying to myself, "If only I had just done this, if only I had just done that." Replay the events over and over again, the exquisite self-flagellation of trauma-induced perfectionism.

But I knew that wasn't the right nor the helpful thing to do. I knew the right thing would be to show up for my community the way the community has shown up for me, and to see the conference through to the end. So I stayed. I was free to attend a talk I was interested in that originally conflicted with mine; the conference organizers had wisely accepted alternate talks. My mistake was ultimately handled gracefully. That's the sign of a well-architected system.

What I learned about myself

Besides the obvious -- which is to not only double check but triple check times -- I learned how much I love giving talks. I feel a certain comfort on stage or in front of an audience, and I find a lot of satisfaction in learning, distilling, and sharing information. I love when someone approaches me afterwards and says, "Your talk taught me something new." I didn't realize how much I had been looking forward to giving my talk until I didn't get to do it.

I also learned that my investment in my community doesn't go unnoticed, and that kindness, understanding, and loyalty are a positive feedback loop. The more you give, the more you get in return. No one was mad at me, I am welcome to continue participating in these events, and I was even asked to sign a thank you card for the organizer. "We love you, Liz," he said when I asked if he was sure he wanted to include my name.

I am still upset about it, I am still ruminating on all the things I should have done that I didn't do. I am not not beating myself up about it. The day after hasn't been easy.

I am trying to remember the understanding and forgiveness I was shown -- and I am trying to learn to grant myself the same kind of compassion. I hope the next time you screw up (because you will screw up), you remember this post, and it's okay if you can't quite muster up the compassion and grace, but I sincerely hope you will try.

The talk that could have been: Even more about Pydantic

The talk extends this blog post, which was also repurposed as a video. You can check out the code here, and the code for the extended talk here.

Using those resources as your foundation, here's even more about Pydantic.

Pydantic under the hood

At a high level, Pydantic follows the principle of "don’t just validate, parse it" –- an idea made popular by software engineer Alexis King.

The distinction is whether an input value is already the required type or whether it can be converted into that type. So instead of simply asking, "Is this input already an integer?" (True or False), Pydantic then asks, "Can this input be converted into an integer?" If the input cannot be parsed, then Pydantic raises a ValidationError. (Of course, this is in lax mode, which is Pydantic's default for type coercion.)

However, all of this parsing and validation can involve substantial work when processing large or deeply nested data. Pydantic uses pydantic-core –- a high-performance validation and serialization engine implemented in Rust –- to handle this.

So on the top layer you've got Pydantic, which provides:

Python-facing API
Model definition
A pleasant developer experience

And below that, you've got pydantic-core, which gives you:

Schema execution engine
Validation and serialization
And that Rust implementation which improves performance because it runs as compiled native code, which is “closer to the machine”

In this example, we see how the input value "14" (a string) is converted to an integer according to the schema we've defined in our Pug class:

from pydantic import BaseModel, Field

class Pug(BaseModel):
    name: str = Field(..., min_length=2, description="The pug's name")
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

name = "Matty"
age = "14"

print(f"type of `name`: {type(name)}")
print(f"type of `age`: {type(age)}")

print("Creating a new Pug ...")

new_pug = Pug(name=name, age=age)
print(f"type of `name`: {type(new_pug.name)}")
print(f"type of `age`: {type(new_pug.age)}")
print(f"Here's your new_pug {new_pug}")

This generates the following output where we can see that the input type for age is a str. When we check the type of the value for age after creating a Pug, we see that the type is int:

type of `name`: <class 'str'>
type of `age`: <class 'str'>
Creating a new Pug ...
type of `name`: <class 'str'>
type of `age`: <class 'int'>
Here's your new_pug name='Matty' age=14 color='fawn'

When we create a Pug class that inherits from BaseModel, Pydantic generates a core schema describing the model's structure and behavior.

This schema is represented as a nested dictionary and is used by pydantic-core for validation and serialization. We can see that in the following example when we step into the __pydantic_core_schema__ attribute of Pug and check its type:

pprint(Pug.__pydantic_core_schema__)
print(type(Pug.__pydantic_core_schema__))

This is the output generated:

{'cls': <class '__main__.Pug'>,
 'config': {'title': 'Pug'},
 'custom_init': False,
 'metadata': {'pydantic_js_functions': [<bound method BaseModel.__get_pydantic_json_schema__ of <class '__main__.Pug'>>]},
 'ref': '__main__.Pug:4336583408',
 'root_model': False,
 'schema': {'computed_fields': [],
            'fields': {'age': {'metadata': {},
                               'schema': {'type': 'int'},
                               'type': 'model-field'},
                       'color': {'metadata': {},
                                 'schema': {'default': 'fawn',
                                            'schema': {'type': 'str'},
                                            'type': 'default'},
                                 'type': 'model-field'},
                       'name': {'metadata': {'pydantic_js_updates': {'description': 'The '
                                                                                    "pug's "
                                                                                    'name'}},
                                'schema': {'min_length': 2, 'type': 'str'},
                                'type': 'model-field'}},
            'model_name': 'Pug',
            'type': 'model-fields'},
 'type': 'model'}
<class 'dict'>

When we step into __pydantic_validator__ and __pydantic_serializer__, we see that they are built on Pydantic's pydantic-core machinery:

print(type(Pug.__pydantic_validator__))
print(type(Pug.__pydantic_serializer__))

And the output is here:

<class 'pydantic_core._pydantic_core.SchemaValidator'>
<class 'pydantic_core._pydantic_core.SchemaSerializer'>

In this example, we explicitly invoke the Pydantic validation machinery with validate_python():

name = "Matty"
age = "14"

print("Creating a new Pug using familiar Python object instantiation syntax ...")
new_pug = Pug(name=name, age=age)
print(f"Here's your new_pug {new_pug}")

print("Creating a new Pug twin using the Pydantic method `validate_python` ...")
data = {"name": name, "age": age}
new_pug_twin = Pug.__pydantic_validator__.validate_python(data)
print(f"Here's your new_pug_twin {new_pug_twin}")

In the output, we get the same result:

Creating a new Pug using familiar Python object instantiation syntax ...
Here's your new_pug name='Matty' age=14 color='fawn'
Creating a new Pug twin using the Pydantic method `validate_python` ...
Here's your new_pug_twin name='Matty' age=14 color='fawn'

What's important to note here is how we create a Pug with familiar Python syntax, but by inheriting from BaseModel, we are actually using Pydantic to validate our input data and create an instance of Pug.

As mentioned, Pydantic also generates structured errors as opposed to obtuse stack traces. In this example, we trigger a ValidationError by providing input that cannot be parsed and does not meet the constraints we defined:

name = "J"
age = "fourteen"

malformed_pug = Pug(name=name, age=age)

As a result, we get a clear ValidationError with explicit messaging:

ValidationError: 2 validation errors for Pug
name
  String should have at least 2 characters [type=string_too_short, input_value='J', input_type=str]
    For further information visit https://errors.pydantic.dev/2.13/v/string_too_short
age
  Input should be a valid integer, unable to parse string as an integer [type=int_parsing, input_value='fourteen', input_type=str]
    For further information visit https://errors.pydantic.dev/2.13/v/int_parsing

If we step into ValidationError we can see the error details generated by pydantic-core, rather than leaving us with an unstructured traceback:

try:
    Pug(name=name, age=age)
except ValidationError as exc:
    pprint(exc.errors())

[{'ctx': {'min_length': 2},
  'input': 'J',
  'loc': ('name',),
  'msg': 'String should have at least 2 characters',
  'type': 'string_too_short',
  'url': 'https://errors.pydantic.dev/2.13/v/string_too_short'},
 {'input': 'fourteen',
  'loc': ('age',),
  'msg': 'Input should be a valid integer, unable to parse string as an '
         'integer',
  'type': 'int_parsing',
  'url': 'https://errors.pydantic.dev/2.13/v/int_parsing'}]

Real world Pydantic: The Vonage Python SDK

The following examples are from the blog post, so you can read more about them there. We'll look at the significant parts.

This demo code uses Vonage Verify to create a sample email OTP authentication workflow application. You can sign up for free and try it out. (All links and steps for creating a Vonage account and application are in the README.)

The Vonage Python SDk got an overhaul in 2024 and one of the big updates is its use of Pydantic for requests and responses.

This is what the VerifyRequest object looks like. Notice how it extends the Pydantic BaseModel. The @model_validator(mode='after') decorator is also provided by Pydantic for additional input validation:

class VerifyRequest(BaseModel):
    """Request object for a verification request."""

    brand: str = Field(..., min_length=1, max_length=16)
    workflow: list[
        Union[
            SilentAuthChannel,
            SmsChannel,
            WhatsappChannel,
            VoiceChannel,
            EmailChannel,
        ]
    ]
    locale: Optional[Locale] = None
    channel_timeout: Optional[int] = Field(None, ge=15, le=900)
    client_ref: Optional[str] = Field(None, min_length=1, max_length=16)
    code_length: Optional[int] = Field(None, ge=4, le=10)
    code: Optional[str] = Field(None, pattern=r'^[a-zA-Z0-9]{4,10}$')

    @model_validator(mode='after')
    def check_silent_auth_first_if_present(self):
        if len(self.workflow) > 1:
            for i in range(1, len(self.workflow)):
                if isinstance(self.workflow[i], SilentAuthChannel):
                    raise VerifyError(
                        'If using Silent Authentication, it must be the first channel in the "workflow" list.'
                    )
        return self

In order to see how Pydantic can serve us in the real world, let's look at this demonstration comparing the use of Pydantic to create and validate a Verify API request versus manually creating the request. It does so using unittest to see what happens when we provide invalid input data:

class TestMain(unittest.TestCase):

    test_data = {
        "brand": 12345,
        "to_email": 678910,
        "channel_timeout": "sixty",
        "code_length": "five",
    }

    def test_without_pydantic(self):

        expected_result = 202
        test_result = without_pydantic(self.test_data)

        self.assertEqual(
            test_result.status_code,
            expected_result,
            msg=f"Test without Pydantic failed with: {test_result.status_code}. Expected: {expected_result}",
        )

    def test_with_pydantic(self):

        expected_result = 202
        test_result = with_pydantic(self.test_data)

        self.assertEqual(
            test_result.status_code,
            expected_result,
            msg=f"Test with Pydantic failed with: {test_result.status_code}. Expected: {expected_result}",
        )

Please note that these tests don't use any mocks, so running them makes real API calls which may incur costs.

Running the tests produces the following outcome:

test_with_pydantic (tests.test_main.TestMain.test_with_pydantic) ... ERROR
test_without_pydantic (tests.test_main.TestMain.test_without_pydantic) ... FAIL

What's important to note here is that the test using Pydantic errors out as opposed to failing. This is because Pydantic catches the incorrect request body parameters when the VerifyRequest object is created:

pydantic_core._pydantic_core.ValidationError: 1 validation error for EmailChannel
to
  Input should be a valid string [type=string_type, input_value=678910, input_type=int]
    For further information visit https://errors.pydantic.dev/2.13/v/string_type

The test without Pydantic fails because the result is a 422 and not a 202 which is the API response for invalid parameters:

AssertionError: 422 != 202 : Test without Pydantic failed with: 422. Expected: 202

This indicates that the Verify endpoint was called despite invalid parameters -- something that Pydantic caught before making a call to the API. This demonstrates how Pydantic validates models at creation and can help prevent wasted API calls.

In summary

In this version of the talk, we go beyond how Pydantic builds on type annotation while maintaining the flexibility of duck-typing to check the validity of any input data before executing functions on it. We take a look under the hood to see how the Rust-based pydantic-core engine handles schema generation, validation, and serialization without straying from the developer-friendly experience of using a human-readable language like Python. This allows us to understand how Pydantic is ideal for implementing APIs like Vonage Verify by validating input data before any request is made.

Seeking validation

I titled this talk "Seeking validation" as a pun. Writing and giving talks about technical concepts is how I process and integrate new knowledge because in order to teach, you really have to understand your subject. In other words, this process helps me validate my understanding.

I guess the pun is even funnier and more applicable now. I didn't validate my conference call time and, as a result, my talk didn't happen. I guess that's actually a really meta demonstration of Pydantic.

When I think about it that way, maybe I didn't screw up after all.

Seeking Validation: Data Validation in Python with Pydantic and Vonage Verify

Liz — Thu, 06 Aug 2026 19:59:45 +0000

This blog post provides an introduction to Pydantic, the popular data validation library for Python. It includes a demonstration of the value Pydantic provides using the Vonage Verify API.

Introduction

What is Duck-typing in Python?

To understand why Pydantic is such a useful library, it is important to first understand how typing works in Python. In programming, “typing” refers to systems of classifying and categorizing data. How data is typed determines how it can be acted upon – for instance, you can’t add the word “two” with the number 2.

Python owes a lot of its success and popularity to its flexibility around typing. Unlike most compiled languages that require you to explicitly declare types, Python implements something called duck-typing. Duck-typing is a dynamic type system that assumes that if an object “walks like a duck and quacks like a duck, then it must be a duck.”

More specifically, according to the Python documentation, duck-typing is:

“A programming style which does not look at an object’s type to determine if it has the right interface; instead, the method or attribute is simply called or used … By emphasizing interfaces rather than specific types, well-designed code improves its flexibility by allowing polymorphic substitution. Duck-typing avoids tests using type() or isinstance().”

In practice, an example of this is Python’s len function. len() returns “the length (the number of items) of an object.” In the code below, observe how len() successfully produces an output regardless of the type of object it is called with:

>>> example_1 = "Hello? World!"
>>> type(example_1)
<class 'str'>

>>> example_2 = [1, 3, 5, 8]
>>> type(example_2)
<class 'list'>

>>> example_3 = {"hello" : "world", "foo": "bar"}
>>> type(example_3)
<class 'dict'>

>>> len(example_1)
13                                 # 13 letters in "Hello? World!"

>>> len(example_2)
4                                  # 4 items in the list

>>> len(example_3)
2                                  # 2 key-value pairs in the dictionary

In an example of dynamic typing that more likely represents what you might see in Python in the real world, the code below defines three different classes of dog breeds that can each bark():

class Pug:
    def bark(self):
        print("The pug goes arf arf!")

class LabradorRetriever:
    def bark(self):
        print("The labrador retriever goes arf arf!")

class Wolfhound:
    def bark(self):
        print("The wolfhound goes arf arf!")

You can instantiate one of each kind of dog breed and call bark() on every one of them without error because they all possess the same interface. Because of duck-typing, the following code runs successfully:

>>> pets = [Pug(), LabradorRetriever(), Wolfhound()]

>>> for pet in pets:
...     pet.bark()

The pug goes arf arf!
The labrador retriever goes arf arf!
The wolfhound goes arf arf!

pet can be of class Pug, LabradorRetriever, or Wolfhound and Python will still call the bark function without error.

This can be convenient, and in many contexts, it's exactly what you want. For scripting, data science, and exploratory work, Python's dynamic typing is a feature, not a bug. Duck-typing lets you iterate quickly without the overhead of rigid type declarations. This is a big part of why Python has become the dominant language for AI and data science workflows.

However, the calculus changes significantly in production backend code. A Flask or Django application with no declared types can introduce maintenance and debugging friction. With Python’s duck-typing, type mismatches surface as cryptic runtime errors rather than clear, early failures. The problem becomes even more acute when applications rely on specific types of data in order to run as intended, such as when working with APIs, processing configuration files, or handling user input.

For instance, if you defined the following class:

class Sphynx:
    def meow(self):
        print("The sphynx goes meow meow!")

And then updated the example code to include an instance of Sphynx in the list of pets to iterate through, you will run into an error:

>>> pets = [Pug(), LabradorRetriever(), Sphynx()]

>>> for pet in pets:
...     pet.bark()
...     

The pug goes arf arf!
The labrador retriever goes arf arf!
Traceback (most recent call last):
  File "<python-input-74>", line 2, in <module>
    pet.bark()
    ^^^^^^^^
AttributeError: 'Sphynx' object has no attribute 'bark'

As this example illustrates, within certain contexts, the flexibility of duck-typing becomes a liability. For example, a wrong type passed to an API call might not fail until the request is already in flight, potentially costing you money on a chargeable call that was always destined to fail.

One way to address some of the issues that arise with dynamic typing is with Python’s type hints.

What Are Type Annotations?

A type hint is a code annotation that “specifies the expected type for a variable, a class attribute, or a function parameter or return value.” Therefore, a type annotation refers to how type hints are used syntactically in Python.

The following code is a basic example of using type annotation:

def greeting(name: str) -> str:
    return 'Hello ' + name

In this example, the type hint is str and the type annotation is the name: str and -> str syntax. The type annotation tells us that the expected type of the parameter name is a string and that the expected return type of the function greeting is a string.

Adding type annotations to the example Pug class could look like this:

class Pug:
    def init(self, name: str) -> None:
        self.name: str = name

    def bark(self) -> None:
        print(f"The pug {self.name} goes arf arf!")

And if we update our pets iteration code to include type annotation, it could look like this:

def make_dogs_bark(pets: List[Pug | LabradorRetriever | Wolfhound ]) -> None:
    for pet in pets:
        pet.bark() 

make_dogs_bark([Pug(), LabradorRetriever(), Sphynx()])

As the name suggests, these are merely type hints. They help make the code more readable and maintainable, but they are not enforced by the Python interpreter. We could use an additional tool like mypy to check the types and receive an error like this:

error: List item 2 has incompatible type "Sphynx"; expected "Pug | LabradorRetriever | Wolfhound"  [list-item]

This would have to be performed as an additional step – nothing is preventing this code from executing and generating an error at runtime.

Seeking Validation

To prevent errors at runtime – such as an API call with incorrect data – you could validate the data in your request before sending it. In the example code, we could define some sort of validation to ensure each item in the list pets can bark():

def make_dogs_bark_safely(dogs):
    """Manual validation in the function"""
    for dog in dogs:
        if not hasattr(dog, 'bark') or not callable(getattr(dog, 'bark')):
            raise TypeError(f"Invalid dog type: {type(dog).__name__}")
        dog.bark()

# Now this fails immediately with a clear message:
pets = [Pug(), Sphynx()]

make_dogs_bark_safely(pets)
# TypeError: Invalid dog type: Sphynx

In addition to quickly becoming tedious and unwieldy, this pattern undermines some of the conveniences of Python’s inherent dynamic-typing while also missing out on some of the benefits of type annotation.

Fortunately, Pydantic provides data validation while maintaining the ease and speed of the language using syntax already baked in.

What is Pydantic?

Pydantic is a data validation library for Python offering the following benefits:

Leverages type hints to control schema validation and serialization.
Uses Rust under the hood for its core validation logic resulting in minimal impact on performance.
Supports validation of many standard library types including dataclass and TypedDict.
Works in either strict or lax mode when handling types.
Can output JSON Schema out of the box, which enables seamless integration with other tools.
Automatically generates documentation from models.

Let’s take a closer look at how these features come together in practice to provide reliable, efficient data validation in harmony with Python syntax and structure.

Core Validation Features of Pydantic

It is important to understand that in Pydantic, “validation” refers to “the process of instantiating a model (or other type) that adheres to specified types and constraints.” In other words, Pydantic’s validation applies to the output of a model instantiation, not the input data. As such, Pydantic raises a ValidationError when data cannot be successfully parsed into an instance of a model.

BaseModel

BaseModel lies at the heart of Pydantic. You inherit from it to define data models with type-annotated fields. One of the primary methods to define schema in Pydantic is via models. When you instantiate a BaseModel Pydantic automatically validates the data against the defined schema.

Using Pydantic, the Pug class now looks like this:

class Pug(BaseModel):
    name: str
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

If you were to instantiate Pug, Pydantic would make sure the resulting object has a name of type string, an age of type integer, and a color of type string with fawn as the default.

Type Hints and Required Fields

Type annotations control schema validation and serialization. Fields declared with just a type annotation are required; fields with defaults are optional.

In the Pug example, the name field is annotated with str meaning any string will suffice, but a string must be provided; the same applies to the age field. The color field, however, provides a default of fawn and thus not required when instantiating a Pug.

Type Coercion

Pydantic can be used in either strict or the default lax mode. In lax mode, the library will automatically convert data to the type defined in the schema.

So, for example, if we supplied "5" as a string for the age of a Pug, Pydantic would convert it to an integer.

Field Configuration

The Field function enables the addition of metadata and constraints for schema fields.

Some commonly used parameters are:

Constraints such as greater than gt) and greater than or equal to ge), and min_length and max_length
Aliases for mapping input and output field names using alias, validation_alias, and serialization_alias)
Strict mode to prevent type coercion on certain fields strict=True)

To enforce constraints on the name field for Pug, you would use the following code:

class Pug(BaseModel):
    name: str = Field(..., min_length=1, description="The pug's name")
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

Serialization

Pydantic model instances can be converted to dictionaries without writing any additional serialization code by using model_dump(). This makes it straightforward to serialize to JSON or other formats to use elsewhere in a project. For example, model_dump_json() serializes a model directly to JSON.

Below is an example of creating an instance of Pug and then serializing it using one of Pydantic’s built-in functions:

matty_pug = Pug(name="Matty", age=14)

result = matty_pug.model_dump()

print(result)

Which would produce the following output:

{'name': 'Matty', 'age': 14, 'color': fawn}

What is a Real-World Use Case of Pydantic?

Since its inception, Pydantic has quickly become one of the most widely used data validation libraries for Python. Approximately 8,000 packages on PyPI use Pydantic including (and most famously) FastAPI, huggingface, Django Ninja, SQLModel, LangChain, and Vonage.

In November 2024, Vonage released a full, ground-up rewrite of the Vonage Python SDK. It’s not always easy to start over completely, but the rewrite was an opportunity to make some critical structural enhancements and improve user interaction with the SDK.

Among some of the changes included in this initiative was the addition of Pydantic to the SDK in order to facilitate calling Vonage APIs and parsing the responses.

Check out the video below to hear from one of our developers who works on the Python SDK and see what he has to say about using Pydantic.

How the Vonage Python SDK Uses Pydantic Models

Using Pydantic models to form requests enforces correct typing and makes it easier to pass the right objects to the Vonage APIs. With version 4 of the SDK, API responses are now deserialized into fully documented Pydantic models, which provide more consistency than returning dictionaries like in the prior version. Additionally, you can still turn Pydantic models into dictionaries or JSON strings with model.model_dump and model.model_dump_json respectively.

For this demonstration, we’ll take a look at the Vonage Verify API and how it is modeled using Pydantic in the SDK.

What is the Vonage Verify API?

The Verify API is Vonage’s next generation two-factor authentication (2FA) product. With Verify API, you can authenticate your users and prevent fraud with a simple, easy-to-use API that abstracts away the complexity of 2FA at a global scale.

It expands on traditional authentication methods by supporting a wider range of channels, including over-the-top (OTT) channels like WhatsApp, as well as SMS, voice, and email. The API supports both JSON web tokens (JWT) and Basic authentication. Basic authentication is easier to get started with, but does not support advanced features such as ACLs. You can use either JWT or Basic authentication, but not both at the same time. You can read more about authentication in the documentation.

At a high level, the Verify API follows this workflow:

An end-user triggers a 2FA request in an application
On the backend, this 2FA request initiates a Verify API request
The Verify API sends a one time password (OTP) to the end-user via the configured channel (SMS, voice, WhatsApp, or email)
The end-user provides the OTP to the application
This initiates a Verify request to check the OTP provided by the end-user against the OTP generated by the API
The result of that check then determines what happens next (the end-user is authenticated, etc)

A diagram of the Verify V2 Request with Summary Callbacks.
A typical initially verification request includes the following payload:

{

   "locale": "es-es",
   "channel_timeout": 180,
   "client_ref": "myPersonalRef",
   "code_length": 4,
   "code": "e4dR1Qz",
   "brand": "ACME",
   "template_id": "4ed3027d-8762-44a0-aa3f-c393717413a4",
   "workflow": [
      {
         "channel": "sms",
         "to": "44770090000"
      },
      {
         "channel": "voice",
         "to": "44770090000"
      }
   ]
}

Which is explained more in-depth below:

Key	Description	Required or optional
locale	The locale to use for the verification message	Optional, defaults to `en-us`
channel_timeout	The time in seconds to wait between attempts to deliver the verification code	Optional, defaults to 180 seconds
client_ref	A unique identifier for the verification request	Optional
code_length	The length of the verification code to generate	Optional, defaults to 4
code	An optional alphanumeric custom code to use, if you don't want Vonage to generate the code	Optional
brand	The name of the company or service that is sending the verification request – this will appear in the body of the SMS or TTS message	Required, maximum length of 16 characters
template_id	A custom template ID to use – works only when `channel` is `sms` or `rcs`	Optional
workflow	The list of channels to use in the verification workflow, used in the order they are listed	Required, maximum length of 3 items

To learn more about the API and how it works, refer to the Vonage Verify documentation.

A successful request responds with a 202 OK to indicate that the verification request has been initiated. The response will also include a request_id which is required to complete the verification process:

{"request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",}

At the same time, Vonage sends an OTP to the end-user via the configured workflow, attempting each channel in the order in which they are defined.

Once the end-user receives and provides the OTP to the application, another request to the Verify endpoint with the request_id as a path parameter https://api.nexmo.com/v2/verify/:request_id) and the OTP in the request body for the code key.

If the code provided matches the code generated and sent by Vonage, a 200 OK response is returned along with a "status": "complete" .

Demonstration: How Does the Verify API Use Pydantic?

The Vonage Python SDK facilitates implementing the Vonage APIs within a Python application. Introducing Pydantic to the SDK makes it even easier to use the APIs. With Pydantic, rather than discovering an error after making an API call and incurring any charges, request models are validated before execution without the need for additional code to do so.

The demonstration for this blog post is a minimal 2FA application using the FastAPI framework. The end-user navigates to a web page where they enter their email address. Using the Verify API, the application then generates an OTP code which is sent to the end-user provided email address. The end-user provides that code to the application and if the Verify check is successful, the end-user is rewarded with an animated gif.

If you want, you can go straight to the code and use the README to get it up and running.

The following code is where the Verify request is created:

   verify_request = VerifyRequest(
        brand=settings.verify_brand_name,
        workflow=[
            EmailChannel(to=email),
        ],
        channel_timeout=60,
        code_length=5,
    )

If we step into the VerifyRequest object, we find a Pydantic model:

class VerifyRequest(BaseModel):
    brand: str = Field(..., min_length=1, max_length=16)
    workflow: list[
        Union[
            SilentAuthChannel,
            SmsChannel,
            WhatsappChannel,
            VoiceChannel,
            EmailChannel,
        ]
    ]
    locale: Optional[Locale] = None
    channel_timeout: Optional[int] = Field(None, ge=15, le=900)
    client_ref: Optional[str] = Field(None, min_length=1, max_length=16)
    code_length: Optional[int] = Field(None, ge=4, le=10)
    code: Optional[str] = Field(None, pattern=r'^[a-zA-Z0-9]{4,10}$')

    @model_validator(mode='after')
    def check_silent_auth_first_if_present(self):
        if len(self.workflow) > 1:
            for i in range(1, len(self.workflow)):
                if isinstance(self.workflow[i], SilentAuthChannel):
                    raise VerifyError(
                        'If using Silent Authentication, it must be the first channel in the "workflow" list.'
                    )
        return self

The schema translates the API request into types using Python annotation and the Field function to define constraints. The workflow field defines a Union type of other modeled types, demonstrating how types can be nested.

Lastly, the model_validator(mode='after') is a Pydantic decorator that provides additional configuration for how the VerifyRequest model is to be validated. In this case, the def check_silent_auth_first_if_present method is executed after the VerifyRequest model has been constructed to ensure that if SilentAuthChannel is included in the workflow, it must be listed first.

Verification By Email

To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit. Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.

After generating and activating a virtual environment, and installing the required dependencies per the README, you can run the demonstration application with the following:

fastapi dev

This will spin up a web app on http://127.0.0.1:8000:

A screenshot of the index page inviting the end-user to enter their email address to try out the Vonage Verify API.

Clicking on Submit verification code triggers the Verify API workflow. You should be directed to a web page where you can enter the code sent to the email address you provided:

A screenshot of the verification page inviting the end-user to enter the code they received in their email.

Entering the correct code here will direct you to a success page.

Under the hood, the code makes use of the Pydantic models in the SDK to ensure the Verify request is correctly formed and handled.

Verification Without Validation: Testing Without Pydantic

Now let’s take a look at how Pydantic facilitates the Verify API.

In the following code, we have two functions that perform the same task: make a request to the /verify endpoint. One of the functions creates the request body manually and the other one uses Pydantic.

Using a manually created request body:

def without_pydantic(request_payload):

    jwt_client = JwtClient(
        application_id=settings.vonage_application_id,
        private_key=settings.vonage_private_key_path,
    )

    jwt_token = jwt_client.generate_application_jwt()

    payload = {
        "brand": request_payload["brand"],
        "workflow": [
            {
                "channel": "email",
                "to": request_payload["to_email"],
            }
        ],
        "channel_timeout": request_payload["channel_timeout"],
        "code_length": request_payload["code_length"],
    }

    response = requests.post(
        "https://api.nexmo.com/v2/verify",
        headers={
            "Authorization": f"Bearer {jwt_token.decode()}",
            "Content-Type": "application/json",
        },
        json=payload,
    )

    return response

Using Pydantic:


def with_pydantic(request_payload):

    client = Vonage(
        Auth(
            application_id=settings.vonage_application_id,
            private_key=settings.vonage_private_key_path,
        )
    )

    verify_request = VerifyRequest(
        brand=request_payload["brand"],
        workflow=[EmailChannel(to=request_payload["to_email"])],
        channel_timeout=request_payload["channel_timeout"],
        code_length=request_payload["code_length"],
    )

    client.verify.start_verification(verify_request)

    last_response = client.http_client.last_response

    return last_response

The code then uses unittest to test the functions with test_data that violates the API parameters:

   test_data = {
        "brand": 12345,
        "to_email": 678910,
        "channel_timeout": "sixty",
        "code_length": "five",
    }

Run the tests with the following command:

python -m unittest -v

Running the tests should result in two different outcomes: an error and a failure.

The test for the function that uses Pydantic should return this error:

pydantic_core._pydantic_core.ValidationError: 1 validation error for EmailChannel
to
  Input should be a valid string [type=string_type, input_value=678910, input_type=int]
    For further information visit https://errors.pydantic.dev/2.13/v/string_type

What’s important to note here is that the test did not fail – instead it errored out because Pydantic caught an incorrect data type before the request was made. Moreover, the error message itself provides useful information for debugging instead of a general type error message. Not only do we know that the data type provided did not meet the model requirements, we also know what the expected type is as well as the type that was passed in:

Input should be a valid string [type=string_type, input_value=678910, input_type=int]

The test for the function without Pydantic returns a failure:

AssertionError: 422 != 202 : Test without Pydantic failed with: 422. Expected: 202

This means that the request was made and, as the API is defined, returned a 422 for invalid parameters.

In this limited test scenario, one bad API call is negligible – on a broader scale, this can be an expensive mistake. Using Pydantic to validate a request model before making the API call helps minimize wasted API calls, enables more graceful error handling, and facilitates developers.

In Summary

Pydantic offers a powerful, performant solution for data validation in Python, helping developers move beyond the potential pitfalls of duck-typing. By defining schema, constraints, and validation rules with Pydantic models, you can ensure data integrity and catch errors before API requests are ever sent. This saves you from costly invalid API calls and makes error handling more graceful.

As demonstrated with the Vonage Python SDK's integration with the Verify API, Pydantic makes it straightforward to work with complex, nested request models while keeping your code readable and maintainable. With version 4 of the SDK, API responses are deserialized into fully documented Pydantic models, giving you more consistency, better tooling support, and a cleaner developer experience overall.

The Vonage Dev Discussion: Everyone loves Pydantic

Liz — Thu, 30 Jul 2026 18:03:50 +0000

We’re back with another Vonage Dev Discussion!

If you’re a Python developer, chances are you’ve heard of Pydantic.

Pydantic is a data validation library for Python. Since its release in 2017, Pydantic has quickly become one of the most popular dependencies in software, reaching 10 billion downloads in 2026 🤯

But why is Pydantic so popular? We could name a few reasons – one of them being that it helped improve our Python SDK when we did a rewrite of it a couple of years ago.

But what do you think? 🤔

Why do you use Pydantic? What are some good use cases for it? How would you explain Pydantic to a beginner?

(By the way, if you’re totally new to Pydantic, we've got this gentle introduction to help you out!)

Let us know your thoughts about Pydantic in the comments below! 🐍👇

The Vonage Dev Discussion: How AI is transforming software development

Liz — Thu, 21 May 2026 19:25:53 +0000

Welcome back to the Vonage Dev Discussion! Recently, members of the Vonage Developer Relations team met up in New York to create content, make plans, and hang out. We even got the chance to record at a super cool studio in the Big Apple!

We took the opportunity to chat about something that’s been on everybody’s mind: artificial intelligence. We talked about how AI is impacting developer relations and tech in general.

We have a second part coming out soon, but in the meantime, we want to know: What’s one thing that AI helps you with? Where do you still prefer to do the work yourself?

We’d love to hear your thoughts in the comments below 🤖👇

The Vonage Dev Discussion: Defining what an API is

Liz — Wed, 13 May 2026 20:49:48 +0000

This week we kicked off the first in a series of office hours. Our office hours are a judgment-free space for developers to come and ask questions about using Vonage – and get an answer live from an actual human!

Being able to ask questions without fear of judgment is so important for beginner engineers and being able to answer those questions is equally important for senior engineers. Have you ever noticed how explaining something makes you really think about what you actually know or don’t know? It's a really good feedback loop!

So here’s a chance to test your knowledge: How would you explain what an API is to someone? What are some examples of APIs you use?

And if you’re new to APIs, here’s a walkthrough of how to use one from our office hours:

And don’t worry! If you run into any issues, we can help you out in our next office hours. Check out the office hours schedule and make sure to subscribe to our YouTube channel for future streams and videos ♥️🤓

Let's keep the API conversation going in the comments below! 💻 👇

The Vonage Dev Discussion: Making mistakes

Liz — Fri, 24 Apr 2026 20:01:26 +0000

Nobody is perfect! Even the most seasoned developers have made mistakes – it’s all just part of the learning process.

One mistake that is so common in software development is accidentally pushing secrets to a public repository 🙈🙉🙊

Fortunately, there are lots of different guardrails you can put in place to help prevent the exposure of sensitive information like API keys, and we’ve covered a few of them in these posts about environment variables.

But we’re curious: What are some mistakes you’ve made as a developer? What did you learn from those mistakes?

Share your wisdom in the comments below! 🙏👇

The Vonage Dev Discussion: Builder pattern

Liz — Tue, 07 Apr 2026 16:48:06 +0000

Have you ever heard of the builder pattern? 🧰🏘️

In software development, the builder pattern is a creational design pattern that lets you construct complex objects step by step. It is especially helpful when you have complex classes of objects that can be extended in many different ways.

In this video, our developer advocates Guillaume Faas and Jeremy Foster discuss the builder pattern and how it is implemented in the Vonage .NET SDK.

The builder pattern sparks debate in the dev community. Some swear by it, others see it as over-engineering. We want to know: What's your take?

Do you use the builder pattern?

How do you use it in your own work?

How would you explain it to someone?

Share your experience and knowledge of the builder pattern in the comments below!

⚒️👇

The Vonage Dev Discussion: Open source

Liz — Wed, 25 Mar 2026 16:59:12 +0000

At Women+ in Open Source Day, I got to try my hand at making a contribution to Apache Spark. While I didn’t manage to clone and build the project within the allotted time, I did get to speak with one of the project’s key contributors, Holden Karau, and was inspired by her encouragement for all sorts of people to get involved.

Contributing to open source can be intimidating! And in the age of AI, contributors from diverse perspectives are even more important.

So for our second ever Dev Discussion, we want to know: What is your advice for getting started contributing to open source projects?

Share your advice in the comments below along with links to some of your favorite open source projects! 🖥️ 🎉👇

The Vonage Dev Discussion: Music

Liz — Tue, 17 Feb 2026 20:50:55 +0000

Hey developers! We want to hear from you for a series we’re calling the Dev Discussion.

What is the Dev Discussion? We want it to be a space where we can take a break and talk about the human side of software development.

Our first Dev Discussion topic is about music 🎶

Speaking of music and tech, you’ve probably heard this track while waiting on hold ☎️🎵

Did you know it was composed in 1989 by Darrick Deel and Tim Carleton, a self described, “Yanni-loving computer nerd” who was just “messing around with a drum machine and a synthesizer” in his parents' garage in California?

You can make it your hold music too!

Besides cool drum machines and chill synthesizers, we want to know:

What is currently playing in your headphones?

Does what you listen to change according to what you are working on?

Do you ever work in complete silence?

Feel free to drop those playlists in the comments below 🎶 👇

Don’t Make Assumptions About Assertions: Even with AI you still have to write your unit tests

Liz — Sun, 26 Oct 2025 23:40:26 +0000

This blog post talks about why making assumptions about assertions makes not one “ass,” but two – which is especially true in this new age of AI. You’re not going to like this, but guess what? You still have to write your unit tests. (Sorry!)

But that’s not necessarily a bad thing! If this blog post doesn’t convince you of that, then I at least hope to invite you to reconsider your feelings about unit testing by taking a closer look at the most important component of the AAA test pattern: the assertion.

How to get the most out of this blog post

This blog post is designed to accommodate many different learning styles so you can choose your own adventure:

Jump straight to the code: Use the README to get it up and running locally.
The key to human productivity or a “disconcerting trend”?: A tale of two reports and their findings about AI, developer productivity, and code churn. (And why human generated tests are important.)
A quick review of unit tests: In case you need it.
Writing unit tests doesn’t have to be horrible: How we can use the assert methods included with Python’s unittest framework to make writing tests less awful.
Using more precise assert methods to write better unit tests: A walk-through of some code in which we’ll explore the effects of using different kinds of assert methods so you can experience that “Aha!” moment first-hand.
Resources and references: Links to more information.

AI generated code: The key to human productivity or a “disconcerting trend”?

In June 2022, GitHub Copilot went GA. A year later, in June 2023, a GitHub blog post proclaimed that “AI developer productivity benefits could boost global GDP by over $1.5 trillion,” citing a February 2023 research paper about an experiment in which a group of programmers with “access to GitHub Copilot was able to complete the task [of implementing an HTTP server in JavaScript as quickly as possible] 55.8% faster” than a control group without help from AI.

It is worth noting that of the paper’s four authors, three of them are associated with GitHub or its parent company Microsoft.

In response to this “promise to increase human productivity,” GitClear, a software engineering intelligence platform, asked the question, “How does this profusion of LLM generated code affect quality and maintainability?” To answer that question, GitClear collected 153 million changed lines of code authored between January 2020 and December 2023, and evaluated the data for differences in code quality. At the time, it was the largest known database of highly structured code change data used for this purpose, and included repos owned by Google, Microsoft, Meta, and enterprise C-Corps.

What GitClear found was “disconcerting trends for maintainability.” The authors of the report drew this conclusion from two factors they observed notable changes in following the general availability of GitHub Copilot:

Code churn

“Code churn” refers to the percentage of lines that are reverted or updated less than two weeks after being authored. In other words, this is code that was probably authored in one sprint and then reverted or updated in the next sprint because the changes were either incomplete or erroneous. The report noted that code churn increased around the same time as the release of GitHub Copilot and projected that it would continue to do so.

Added and copy-pasted code

This refers to code that is newly authored instead of code that is “updated,” “deleted,” or “moved.” The report goes on to explain that an increase in adding new code instead of refactoring existing code “resembles an itinerant contributor, prone to violate the DRY-ness of the repos visited.” (DRY is an acronym for the “Don’t Repeat Yourself” tenet of software engineering.) And who might that “itinerant contributor” be? Yup – AI.

(No, AI didn’t write that. I’ve always been a prolific em-dash user so AI probably stole its usage from me.)

So what can we, as developers, take away from this?

While both the GitHub and the GitClear reports don’t try to hide their bias or content marketing intentions, we can still glean some useful insights from them:

You’re probably going to encounter AI generated code – whether you’re the one adding it or you’re reading/reviewing AI generated code that someone else added.
I’m sorry, but you still have to write your unit tests. Now more so than ever.

… but that’s not a bad thing. (Stay with me here.)

A quick review of unit tests

What is unit testing?

Unit testing is the process of evaluating and verifying that the smallest functional units of code do what they are supposed to do individually and independently. So if we have a web application that allows a user to view collections of Pokemon according to ability, color, or type, we might have a Pokemon object with methods that perform tasks such as calling a Pokemon API endpoint, processing whatever response we get back from that endpoint, and then transforming that processed response into something we can display in a browser for the user. Our unit tests would act on each method individually and independently to verify that each method performs as expected.

The idea is that if each “ingredient” of a whole application is correct, then we can assume the end result will turn out the way we want. We can assume that if we have the right kind of tomato sauce, crust, and toppings, our pizza will be edible and delicious.

Unit tests are just one kind of software testing. There are lots of different types of tests that try to answer different types of questions such as, “Do all the different parts of this system actually work together?” and, “What happens if I throw in this totally wild edge case – will my system survive?”

(This is where I trot out my software testing alignment chart because it’s probably one of the most clever things I’ve ever created and people seem to really like it!)

The benefits of unit tests

The benefits of unit tests include:

Preventing bugs
Accelerating development
Saving money

But the most compelling benefit of unit tests is they help us become better engineers. Unit tests force us to ask ourselves, “What actually is the expected behavior of this method?” In the best case scenario, unit tests reveal code smells or redundancy or unnecessary complexity that motivate us to refactor the code under test.

A LinkedIn post in praise of refactoring and why.

Unit tests and AI

“But Liz!” you say, “Writing unit tests is so tedious and boring! Won’t I be more productive if I get AI to write them?”

Maybe.

After all, if these LLMs are trained on millions of lines of code and all of the internet, isn’t using AI to write unit tests kind of exactly like copying and pasting a solution from Stack Overflow? That time-honored tradition of software engineering?

If someone else has already figured it out, why not reuse their solution? Is that not in alignment with the DRY principle?

What could go wrong?

To answer that, here’s an excerpt from the GitHub paper on AI powered productivity mentioned above:

“We included a test suite in the repository, comprising twelve checks for submission correctness. If a submission passes, all twelve tests we counted are successfully completed. Participants could see the tests but were unable to alter them.”

In order to ensure that both the AI enabled and control groups of programmers tasked with spinning up a server did so correctly, the tests were written first. Whether the code was human or AI generated, it was verified with tests provided by the researchers.

And anyway, would you really trust an LLM trained on the tests most developers write?

A LinkedIn post describing why LLMs are bad at writing tests.

Writing unit tests doesn’t have to be horrible

Personally, I would love to one day achieve the disciplined zen of test driven development, but jumping right into the application code is just so much more seductive. It’s like eating dessert first, and while eating dessert first isn’t necessarily “bad” (we’re adults who can make our own decisions), it’s probably not great for us nutritionally in the long run. So how can we write unit tests in a way that is efficient and optimized? Unit tests that are modular and maintainable and leverage all of the tools in our toolkit?

The AAAs of testing

Typically, a test follows this pattern:

Arrange: Set up the test environment. This can include fixtures, mocks, or context managers – whatever is needed to execute the code under test. When it comes to unit tests, the test environments for each test should be isolated from each other.
Act: Execute the code under test. If it’s an end-to-end test, this might mean kicking off a workflow that includes multiple services and dependencies. In a unit test, however, this should be a single method.
Assert: Verify the results. Compare the expected result with the test results – did the code do what you want it to do? This is the most important part of the test and in unit tests, it is (usually) best practice to have one precise assertion per test.

Keeping this pattern in mind can help make it easier to write unit tests.

Don’t make assumptions about assertions

When you make assumptions about assertions, you end up with not one “ass,” but two. Just because you have 100% test coverage and everything is passing, it doesn’t mean your tests are actually meaningful or – and here’s the “galaxy brain” revelation for you – maintainable.

In Python’s untittest specifically, assert methods come included with the TestCase class. These methods check for and report failures. You are probably familiar with the tried and true assertEqual method, in which one argument is compared with another, and if the two do not match, result in a test failure … but did you know that there are so many more specific and precise assertions available to you? All out of the box?

Take a look at these!

Most common assert methods:

Method	Checks that ...
assertEqual(a, b)	a == b
assertNotEqual(a, b)	a != b
assertTrue(x)	bool(x) is True
assertFalse(x)	bool(x) is False
assertIs(a, b)	a is b
assertIsNot(a, b)	a is not b
assertIsNone(x)	x is None
assertIsNotNone(x)	x is not None
assertIn(a, b)	a in b
assertNotIn(a, b)	a not in b
assertIsInstance(a, b)	isinstance(a, b)
assertNotIsInstance(a, b)	not isinstance(a, b)
assertIsSubclass(a, b)	issubclass(a, b)
assertNotIsSubclass(a, b)	not issubclass(a, b)

Assert methods that check the production of exceptions, warnings, and log messages:

Method	Checks that ...
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*
assertRaisesRegex(exc, r, fun, args, *kwds)	fun(args, kwds) raises exc* and the message matches regex r
assertWarns(warn, fun, args, *kwds)	fun(args, kwds) raises warn*
assertWarnsRegex(warn, r, fun, args, *kwds)	fun(args, kwds) raises warn* and the message matches regex r
assertLogs(logger, level)	The with block logs on logger with minimum level
assertNoLogs(logger, level)	The with block does not log on logger with minimum level
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*

Even more specific checks:

Method	Checks that ...
assertAlmostEqual(a, b)	round(a-b, 7) == 0
assertNotAlmostEqual(a, b)	round(a-b, 7) != 0
assertGreater(a, b)	a > b
assertGreaterEqual(a, b)	a >= b
assertLess(a, b)	a < b
assertLessEqual(a, b)	a <= b
assertRegex(s, r)	r.search(s)
assertNotRegex(s, r)	not r.search(s)
assertCountEqual(a, b)	a and b have the same elements in the same number, regardless of their order
assertStartsWith(a, b)	a.startswith(b)
assertNotStartsWith(a, b)	not a.startswith(b)
assertEndsWith(a, b)	a.endswith(b)
assertNotEndsWith(a, b)	not a.endswith(b)
assertHasAttr(a, b)	hastattr(a, b)
assertNotHasAttr(a, b)	not hastattr(a, b)

Type specific assertEqual methods:

Method	Compares ...
assertMultiLineEqual(a, b)	strings
assertSequenceEqual(a, b)	sequences
assertListEqual(a, b)	lists
assertTupleEqual(a, b)	tuples
assertSetEqual(a, b)	sets or frozensets
assertDictEqual(a, b)	dicts

Using a more precise assert method can help refine your unit tests and make the work of writing them more efficient and optimized.

Getting your hands dirty: Using more precise assert methods to write better unit tests

What I appreciate most about developers as an audience is the emphasis on showing rather than telling because personally, I need to see something before I believe it, too. It’s even better when I get to run the code myself and arrive at that “Aha!” moment on my own. Hands-on is the best way to learn.

An artisanal, handcrafted, slow coded Pokemon Flask app

You’ve heard of “no code,” right? Well, get ready for “slow code.”

I wanted to see if I could use Cursor, an AI-powered code editor, to write my unit tests, but I needed some code to test first. I decided to code – by hand – a very simple Pokedex Flask app. Sure, I could have prompted Cursor to do it for me, but that seemed to defeat the purpose of the experiment. Nor does it really simulate a real world use case since most professional developers are probably working with existing pre-AI code, and, more than that, I wanted to write some Python. Isn’t that why I do this? Because it’s enjoyable?

Yeah, it’s “slow code” – and it’s important. Programming is a muscle, and if you don’t exercise it regularly, it atrophies. I understand that the craft of code is often not as important as the profit it produces, but at what cost? I could have prompted an LLM to generate this blog post, but I didn’t, because I like writing. Every blog post I write myself makes me a better writer; every line of code I write makes me a better programmer. It’s that hands-on learning thing.

So I wrote my app by hand, using a forked minimal Flask template to avoid the boilerplate code. I ended up with a web app that uses an API endpoint to view collections of Pokemon according to ability, color, or type. I muddled through the limited JavaScript the app implements and used a Python-wrapped Bootstrap library for the styling. It’s not very complicated so using Cursor to write the unit tests should be a simple task – right?

All the pink Pokemon all in one place.

A look at the AI generated unit tests

My prompt was simple: generate unit tests for pokemon.py using unittest

Let’s take a look at what we ended up with. Feel free to pull down the code here and check it out.

To start things off, let’s see if the tests pass and what kind of coverage they provide.

----------------------------------------------------------------------

Ran 12 tests in 0.008s

OK

Name              Stmts   Miss  Cover

-------------------------------------

pokemon.py           29      0   100%

test_pokemon.py     147      1    99%

-------------------------------------

TOTAL               176      1    99%

Passing tests and 100% coverage. We’re off to a promising start … or are we? Not all coverage is created equally, so it’s worth investigating the tests themselves.

Funky fixtures

def setUp(self):
    """Set up test fixtures before each test method."""
    self.mock_response = Mock()
    self.mock_response.json.return_value = {}

def tearDown(self):
    """Clean up after each test method."""
    pass

We begin benign enough with some test fixtures in which a mock response is created for every test method in the class. Things start to get a little “smelly” when we examine the teardown method, which is just a pass. In this particular case, the mock object would already be inaccessible beyond the test function it is created within, so while the teardown ensures it is truly gone, it’s a little excessive, and renders the whole fixture moot. Test fixtures can be very useful, especially when creating isolated, independent test environments, but in this scenario, it doesn’t seem to be adding to the meaningfulness of the tests.

Furthermore, mock responses are created in each of the test functions, making the fixture even more redundant. (Read more about test fixtures and mocks.)

So already we find ourselves having to refactor AI generated code.

Now let’s take a look at the first test and its assertions.

More maintainable, human friendly tests

Like their source code, tests will need to be updated as a system evolves. The more “finding and replacing” you need to conduct, the more brittle and unreliable your tests are. Using variables instead of “magic values” can reduce the number of instances that require updating. In this example, we’ve replaced the magic test values and expected values with a variable. Our test is now more modular and easier to maintain.

# Act: Execute the code under test
# Test the function

test_input = "type"
test_result = get_attributes(test_input)

# Assert: Check the results

# Add a message for the assert methods
assert_message = f"For test values: {test_input} " \
    f"the function produced: {test_result}."

self.assertEqual(test_result, expected_result)

The TestCase assert methods also take a message argument: assertEqual(arg1, arg2, msg=None) The value provided for msg outputs when a test fails. This can give us more information about a test failure, which makes it easier to fix or debug.

Let’s add a test that will fail:

# Add a test failure to demonstrate ouput
self.assertIsNone("something")

Without a message, this is what our test failure looks like:

AssertionError: 'something' is not None

With a message, and utilizing the variables we created, even our failures become helpful:

# Add a test failure to demonstrate ouput
self.assertIsNone("something", msg=assert_message)

AssertionError: 'something' is not None : For test values: type the function produced: ['fire', 'water', 'grass'].

Too many assertions

There are competing philosophies on the number of assertions that a test should contain. Some people will tell you that a unit test should have only one assertion and others might tell you that more than one is okay. When writing tests, it’s important to remember that the assert methods provided by TestCase “check for and report failures.” Imagine if all of these assertions result in failures you have to then fix or debug. Do these failures actually tell us anything about the code under test?

# Assertions
self.assertIsInstance(result, list)
self.assertEqual(len(result), 3)
self.assertIn("fire", result)
self.assertIn("water", result)
self.assertIn("grass", result)
self.assertEqual(result, ["fire", "water", "grass"])

If we look at the code under test, a list of strings is returned. That’s it, that’s all that happens. While this code is not code you’d want to push to production, it is the code we are testing.

def get_attributes(attribute):
    response = requests.get(BASE_URL + attribute)
    response_json = response.json()

    attributes_list = [item["name"] for item in response_json["results"]]

    return attributes_list

Do we really need to assert on the specific contents of the list? Especially if this particular function doesn’t do anything with those contents? We probably want to reduce the number of assertions in this test. We really only need to test whether or not the code produces a list.

We can do that with assertEqual(test_result, expected_result, msg=test_message or we can eliminate yet another assertion (the assertIsInstance) with assertListEqual which will not only compare the lists, but also verify the list type.

self.assertListEqual(test_result, expected_result, msg=assert_message)

Don’t believe me? Let’s change expected_result to a string and see what happens when we use assertListEqual:

# Change `expected_result` to a string
self.assertListEqual(test_result, "'fire', 'water', 'grass'", msg=assert_message)

AssertionError: Second sequence is not a list: "'fire', 'water', 'grass'"

The test fails. Now we’ve verified not only the test result itself, but the test result type as well.

Can we eliminate another assertion? Let’s see!

Let’s say we want to also make sure we don’t end up with an empty list even though we might not know the exact number of list elements we will end up with. This is where we can use assertGreaterThan and create a variable list_minimum = 0 for the minimum value we can accept – which, in this case, is zero.

self.assertGreater(len(test_result), list_minimum, msg=assert_message)

No comment please

This is just a nit, but the AI generated tests included this comment:

self.assertEqual(result, ["fire", "water", "grass"])  # Order matters for this function

Nothing in the code suggests that, so it’s just a random comment. In response, I added my own useless comment: # No, it doesn't

(I don’t cover the rest of the tests here, but if you check out the code, I’ve commented on the parts of the tests that I would have to refactor if I wanted to make this code production ready.)

Before and after

Comparing the test before and after, our new test is a lot more succinct, meaningful, and maintainable. Now, no matter how the source code evolves, we can rely on this test to tell us if we’ve introduced any breaking changes.

Before:

@patch("pokemon.requests.get")
def test_get_attributes_success(self, mock_get):
    """Test get_attributes function with successful API response."""

    # Mock the response
    mock_response = Mock()
    mock_response.json.return_value = {"results":[
                                                 {"name": "fire"},               
                                                 {"name": "water"},
                                                 {"name": "grass"}]}
    mock_get.return_value = mock_response

    # Test the function
    result = get_attributes("type")

    # Assertions
    self.assertIsInstance(result, list)
    self.assertEqual(len(result), 3)
    self.assertIn("fire", result)
    self.assertIn("water", result)
    self.assertIn("grass", result)
    self.assertEqual(result, ["fire", "water", "grass"])  # Order matters for this function
    mock_get.assert_called_once_with(BASE_URL + "type")

After:

@patch("pokemon.requests.get")
def test_get_attributes_success(self, mock_get):
    """Test get_attributes function with successful API response."""

    # Mock the response
    mock_response = Mock()
    mock_response.json.return_value = {"results":[
                                                 {"name": "fire"},               
                                                 {"name": "water"},
                                                 {"name": "grass"}]}
    mock_get.return_value = mock_response

    # Test the function
    test_input = "type"
    test_result = get_attributes(test_input)

    # Assert
    assert_message = f"For test values: {test_input} " \
        f"the function produced: {test_result}."

    expected_result = ['fire', 'water', 'grass']
    list_minimum = 0

    self.assertGreater(len(test_result), list_minimum, msg=assert_message)
    self.assertListEqual(test_result, expected_result, msg=assert_message)
    mock_get.assert_called_once_with(BASE_URL + 'type')

In conclusion: Unit tests are the human in the loop

Whether your code is meticulously typed out character by character, copied and pasted from Stack Overflow, or generated by an LLM, unit tests are the quickest way to verify it operates as expected. Moreover, when we start with unit tests that are written with as much care and intention as the source code itself, we lay the foundation for efficiency and optimization which makes writing the next set of unit tests much less laborious and tedious. Solid unit tests are an investment in future productivity. While AI can “hallucinate,” it has no imagination or empathy, so it cannot write tests for the humans who will eventually be stuck deciphering test failures.

What do you think? Do you think AI will get better at writing unit tests? Do you feel inspired to try out other assert methods in your testing?

Resources and references

❤️ If you found this blog post helpful, please consider buying me a coffee.

A New Era of Code Quality: Beyond bugs and into legal license compliance and risk management

Liz — Wed, 25 Jun 2025 18:16:46 +0000

In the interconnected world of software, few applications are conjured into existence entirely from scratch. Developers consistently draw upon a vast ecosystem of open-source libraries, frameworks, and external components, all designed to expedite coding and reuse established solutions. It’s simply efficient: Why should anyone invent a solution when a perfectly good one already exists?

However, while incredibly efficient, reliance on third-party components comes with its own baggage: Licensing. It may seem like a minor detail, but failure to understand or comply with the terms of even one license — among the dozens or hundreds typically found in a modern application — can lead to severe legal disputes, the forced open-sourcing of proprietary code, and substantial financial penalties. This makes license compliance a remarkably complex and unglamorous undertaking.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead:

License and litigation and why it’s important to pay attention
The intersection of dependency management, SBOMs, and software licenses
How license management contributes to code quality
More resources and references

License and litigation and why it’s important to pay attention

Modern software projects often have a deep “dependency tree,” where a direct dependency itself relies on other libraries (transitive dependencies). It’s easy to overlook the licenses of these indirect dependencies, leading to hidden compliance risks. Unfortunately, “I didn’t know” is not an excuse that holds up in court.

Not even the biggest corporations are immune to the consequences of license mismanagement. License violations have cost companies millions of dollars, forced code disclosure or refactoring, injunctions, settlements, and precious time and resources that could have been spent otherwise.

The intersection of dependency management, SBOMs, and software licenses

What is an SBOM?

An SBOM acts as a comprehensive, machine-readable inventory of all components within a software package. Much like an ingredients list on a food product, a Software Bills of Materials (SBOM) details every piece of open-source and proprietary software, libraries, and modules that make up a given application, along with their versions and origins. And just as a food label might list “enriched flour” and then detail its components like niacin and thiamine, an SBOM also breaks down your dependencies’ dependencies, giving you a complete picture of every ingredient. For developers, maintaining an up-to-date SBOM is crucial for visibility into their software supply chain, enabling them to track and respond to security advisories more effectively.

An example of an SBOM in JSON according to the CycloneDX format.

What is dependency license management?

As developers, we are usually pretty aware of the importance of checking our “list of ingredients” (albeit often against our will while detangling dependency conflicts) and even if we don’t always immediately address CVEs, we at least know we should probably cut a card for the task. Another aspect of dependencies that we may know less about is license management.

At its core, a software license is a legal agreement that defines the terms under which you can use, modify, and distribute a piece of software. Think of it like a contract between the creator (licensor) and the user (licensee). Most open-source software comes with specific licenses that dictate how it can be used, modified, and distributed. Failing to comply with these licenses can lead to legal complications, intellectual property disputes, and financial penalties. An SBOM can serve as a foundational tool for license compliance, providing a clear record of the licenses associated with each component. This becomes particularly important in environments where certain license types (e.g., strong copyleft licenses like GPL) may have significant implications for the broader software product.

The intersection of SBOMs, CVEs, and licensing forms the backbone of effective dependency management. In an era where AI hallucinations and the accidental inclusion of malicious or problematic packages are growing concerns, the practice of diligent processes for generating and analyzing SBOMs become indispensable to the production and deployment of quality code.

What are the different kinds of software licenses?

These licenses are the legal frameworks that define how you can use, modify, and distribute software, whether you’re building a new application, contributing to an open-source project, or simply using a program on your computer. Understanding the distinctions between these licenses is crucial for avoiding legal pitfalls, ensuring compliance, and making informed decisions about your software projects. Licenses can be broken down into the following broad categories:

Standard permissive: The most commonly used permissive licenses. They grant broad permissions to use and modify with very minimal obligations (primarily attribution) and have all the essential elements of permissive open source licenses. Examples include MIT and Apache software licenses.
Non-standard permissive: Permissive licenses that lack one or more essential elements of modern permissive open source licenses, or impose complex or confusing requirements. Examples include Artistic 1.0 and the WTFPL software licenses.
Weak copyleft: Weak copyleft licenses require sharing your changes and additions to the licensed software when you give copies to others. Examples include GNU LGPL and the Mozilla Public License.
Strong copyleft: In addition to the requirements of the weak copyleft licenses, strong copyleft licenses require you to share larger programs that you build with the licensed software when you give copies to others. Examples include the GNU GPL license.
Network copyleft: In addition to the requirements of strong copyleft licenses, network copyleft licenses require you to share larger programs that you build with the licensed software not just when you give copies to others, but also when you run the software for others to use over the Internet or another network. Examples include the GNU AGPL (Which is different from the GNU LGPL!) and the Server-Side-Public License.
Maximal copyleft: Maximal copyleft licenses answer the question “When does the license require you to share?” differently than other licenses. Maximal copyleft licenses require you to share software you make with others, and to license that software alike when you do. Examples include the Parity and Reciprocal software licenses.
Uncategorized: Nonstandard licenses that do not fit into the above categories.

With SonarQube Software Composition Analysis, each dependency includes information for all the dependencies it relies on so you can see exactly which licenses are being introduced into your project.

How license management contributes to code quality

At a fundamental level, high-quality code embodies these key traits: it’s reliable, secure, and maintainable. Software licensing may not be the first thing that comes to mind when considering code maintainability, but think of it this way: Much like tech debt, leaving license management for later can result in “legal debt” that almost inevitably comes to collect. Dependency trees are already thorny when it comes to keeping versions in line, just imagine having to remove dependencies due to license violations. Or worse — the possibility of being forced to recall a product (and all the effort that went into it). Decommissioned code is not maintainable code.

Moreover, because you can’t oversee the licensing decisions or compliance procedures governing your dependencies’ code, you need an alternative approach to ensure their potential license problems don’t jeopardize your own software’s legal standing. Nowadays, a rigorous and intelligent code quality discipline absolutely must encompass legal considerations like dependency license management.

SonarQube’s Software Composition Analysis (SCA) goes beyond just listing your project’s dependencies. It also provides a comprehensive overview of associated license risks, complete with holistic scoring and actionable remediation steps. This allows you to prioritize and address license compliance issues according to your organization’s specific needs.

💡 Want to learn more about SonarQube Software Composition Analysis? Check out a tutorial here.

More resources and references

Read more about coding best practices here.
Read more about best practices for dependency risk management in particular here.
For a breakdown of other top security flaws and how to address them, check out Jonathan Vila’s article on the topic.
Want to learn more about SBOMs? This article provides a comprehensive overview.

A New Era of Code Quality: Beyond bugs to supply chain security and dependency health

Liz — Wed, 25 Jun 2025 17:57:08 +0000

In today’s interconnected software landscape, most applications don’t just spring up from thin air. Developers are constantly pulling in countless open-source libraries, frameworks, and other third-party components to speed things up and reuse existing solutions. And why not? If a specialized solution already exists for a particular problem, why reinvent the wheel? However, while efficient, this reliance opens up a massive new vulnerability: the software supply chain.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead:

Weak links: Anatomy of a supply chain attack and the new threat AI poses
The intersection of dependency management, SBOMs and CVEs
A stick or a snake: A framework for evaluating risk
How security contributes to code quality
More resources and references

Weak links: Anatomy of a supply chain attack

In the context of cybersecurity, a supply chain attack refers to a cyberattack that targets an organization by infiltrating less secure elements in its extended network of partners, suppliers, or components, rather than directly attacking the primary target itself. Simply put, it’s like a hacker getting to you by attacking someone you do business with.

The core idea is to compromise a trusted third party or a component that the target organization relies on. By doing so, the attackers can then gain unauthorized access or introduce malicious code into the target’s systems, products, or services without directly breaching their main defenses.

Think of it like this: If you want to break into a heavily guarded fortress (the main target), instead of attacking the front gates, you find a weakness in the company that supplies their food or builds their walls, and use that weakness to get inside.

These attacks are particularly dangerous because:

They leverage trust: The malicious element comes from a source that the target organization or its customers inherently rely on.
They have a wide blast radius: Compromising one component or supplier can lead to a ripple effect. That means that even if your organization wasn’t the primary target of such an attack, you can still be compromised.
They are often difficult to detect: The malicious activity might be hidden within legitimate software updates, hardware, or services, making it challenging for standard security measures to identify.

Common vectors for supply chain attacks include:

Software updates: Injecting malware into legitimate software updates, often by compromising the software vendor’s systems or exploiting vulnerabilities in the update delivery mechanism.
Open-source components: Introducing malicious code into widely used open-source libraries that developers then incorporate into their applications.
Hardware tampering: Modifying hardware components during manufacturing or shipping.
Compromised build tools or environments: Attacking the tools or infrastructure used to build software.
Third-party service providers: Gaining access through a less secure vendor that has legitimate access to the target’s systems (e.g., an IT service provider).

We’ve seen this play out in countless high-stakes scenarios, where everyone from savvy cybercriminals to highly resourced, persistent threat actors has leveraged these dependency pathways. These weren’t about traditional application hacks. They were about malicious packages quietly slipped into public repositories, compromised build pipelines, or trusted updates carrying hidden payloads. And it’s not always malicious! Sometimes a supply chain vulnerability is just a really, really big unintentional complication.

As these supply chain attacks and vulnerabilities illustrate, maintaining a clean Software Bill of Materials (SBOM) is critical to code security. An SBOM is essentially a detailed “ingredient list” for your software, identifying all its components, including open-source libraries and third-party code. This transparency helps you understand exactly what’s in your software, which is crucial because bad actors know how challenging it can be to assess, verify, and remediate these hidden supply chain vulnerabilities. In modern software, it’s a constant tightrope act of prioritization with weights that shift as you cross the wire.

But don’t worry — it gets more complex!

First came “vibe coding” …

“Vibe coding” is an emerging approach to software development, heavily reliant on artificial intelligence, particularly large language models (LLMs). First mentioned by AI researcher Andrej Karpathy in early 2025, “vibe coding” describes a process where developers primarily use natural language prompts — speaking or typing in plain language — to instruct AI tools to generate, refine, and debug code. The core idea allows users to focus on describing what they want the software to do (the “vibe” or intent), letting the AI handle much of the how (the actual code implementation), often without the developer needing to fully understand the generated code. This method aims to make software creation more accessible and potentially faster, especially for simpler projects or prototypes.

It has been met with both a great deal of skepticism and support. Love it or hate it, “vibe coding” is changing the way we approach the software development lifecycle, and with these new tools come new challenges.

Now there is “slopsquatting”

Coined by Python Software Foundation Developer-in-Residence Seth Larson and popularized by a Mastodon post from Ecosyste.ms creator Andrew Nesbitt, “slopsquatting” — more formally known as “package hallucination” — is a type of cybersquatting. It is the “practice of registering a non-existent software package name that a LLM may hallucinate in its output.” At best, developers may attempt to install an AI-suggested package only to run into an annoying error; at worst, these false packages are exploited.

For example, if an AI suggests using a non-existent package like super_fast_lib and a malicious actor then registers that name on a public repository, a developer blindly installing it could inadvertently introduce malicious code. This is where a robust Software Bill of Materials (SBOM) becomes crucial: An SBOM would ideally reveal the presence of such an unfamiliar or newly added dependency, alerting security teams to a potential slopsquatting attempt and a vulnerability in their supply chain.

Either way, slopsquatting is yet another threat to software supply chain integrity, and along with all the other risks of vibe coding, further emphasize the need for human oversight in AI-generated code.

Whether it’s a package that doesn’t actually exist or a package that has been deliberately exploited, software dependencies can be a point of weakness in any system. Secure code is an important aspect of the reliability and integrity of your production systems, regardless of whether the code comes from a third-party, AI, or in-house development. Implementing best practices at every step of development helps ensure that code is not only readable and maintainable, but secure as well.

The intersection of dependency management, SBOMs and CVEs

As highlighted by some of the most notable supply chain attacks and the emerging threat of “slopsquatting,” the increasing reliance on third-party software components underscores the critical importance of robust dependency management. This discipline isn’t just about integrating external code, it’s about understanding and mitigating the inherent risks associated with it. Central to this understanding are Software Bills of Materials (SBOMs) and Common Vulnerabilities and Exposures (CVEs).

What is an SBOM?

An example of an SBOM in JSON according to the CycloneDX format.

What is a CVE?

Closely related to SBOMs are Common Vulnerabilities and Exposures (CVEs). A CVE is a publicly available identifier for a known cybersecurity vulnerability. When a vulnerability is discovered in a specific software component (often a library or framework), it is assigned a CVE ID. By cross-referencing components listed in an SBOM with known CVEs, organizations can rapidly identify and prioritize patching efforts for vulnerable dependencies. This proactive approach helps to prevent exploitation by malicious actors who might otherwise leverage unpatched weaknesses. The “SunSpot” malware’s ability to operate with elevated permissions and deploy backdoors underscores the severe consequences of unaddressed vulnerabilities, whether they stem from sophisticated supply chain attacks, more common software flaws, or AI hallucinations.

An example of a CVE record.

A stick or a snake: Not every CVE is a threat to your supply chain

According to CVE.org, 40,077 CVEs were published in 2024, which is a significant jump from 2023’s 28,961 published CVEs. Responding to each and every CVE in a supply chain is neither feasible nor practical and with FIRST (the Forum of Incident Response and Security Teams) predicting an increase of CVEs in 2025, you need to draw on other information to determine best next steps when alerted to a CVE for one of your dependencies.

Imagine you are walking down a road where snakes are known to slither and you see a stick in the distance. You might mistake it for something more dangerous than just an errant piece of wood. If you’ve had the misfortune of a snake bite, you might be biased toward assuming the stick is more than just a stick. Conversely, if you’ve never encountered a snake despite reports of their presence, you might walk too close past what you think is a stick and make your last mistake ever.

Not all dependency vulnerabilities and exposures pose the same risk. How a CVE may affect a system is dependent (See what I did there?) on a few different factors:

The Common Vulnerability Scoring System (CVSS)
The Known Exploited Vulnerabilities (KEV) catalog
The Exploit Prediction Scoring System (EPSS)

With SonarQube Software Composition Analysis, each dependency risk is evaluated holistically. As you can see here, while the CVSS score is high, the EPSS score is closer to medium with no known exploits. This information can help you determine if this CVE is worth addressing and how.

Combining all these facets of a CVE helps provide a more holistic approach to vulnerability remediation. In order to understand how CVSS, KEV, and EPSS come together, it’s important to understand them independently.

What is the CVSS?

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. It provides a numerical score (ranging from 0.0 to 10.0) that reflects the characteristics and severity of a vulnerability. Commissioned by the National Infrastructure Advisory Council (NIAC) and now under the custodianship of the Forum of Incident Response and Security Teams (FIRST), the CVSS was introduced in 2005. Its mission is to standardize vulnerability assessments to empower organizations to evaluate and respond to risks efficiently and effectively.

A CVSS score is determined by three metric groups:

Base: These represent the intrinsic characteristics of a vulnerability and are constant over time and across user environments. They consider factors like attack vector, attack complexity, required privileges, user interaction, scope, and impact on confidentiality, integrity, and availability.
Temporal: These reflect the evolving characteristics of a vulnerability over time. They account for factors such as the maturity of the exploit code, the availability of a fix, and the level of confidence in the existence of the vulnerability.
Environmental: These metrics allow for custom adjustments to the score based on the specific context of an organization’s environment. For example, a vulnerability might be more critical in a system handling sensitive government data than in a less critical internal tool.

To summarize, CVEs provide a unique identifier for a publicly known security flaw while the CVSS provides the numerical severity rating that helps organizations assess the risk associated with a CVE within their specific context. CVSS scores serve as a vital tool for making informed decisions about which dependencies to use, which to patch first, and how to allocate limited security resources most effectively.

An example of a CVSS score.

What is a KEV?

While the CVSS provides a crucial framework for assessing the technical severity of a vulnerability, it doesn’t inherently tell you if that vulnerability is actively being used by attackers “in the wild.” This is where the concept of a Known Exploited Vulnerabilities (KEV) catalog becomes useful.

A KEV catalog is a curated list of vulnerabilities that are known to have been actively exploited by threat actors. Unlike a comprehensive database of all discovered vulnerabilities (which can number in the hundreds of thousands), a KEV catalog focuses on the subset of vulnerabilities that pose an immediate and proven threat because they have already been leveraged in real-world attacks.

The most prominent and widely referenced KEV catalog is maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The CISA’s KEV contributes critically to cybersecurity by:

Prioritizing remediation: If a dependency in your software has a CVE that appears on the KEV list, it signifies an urgent need for patching or mitigation, regardless of its CVSS score. (Not surprisingly KEVs often have high CVSS scores.) The fact that a vulnerability has been exploited means it’s not a theoretical risk, but a clear and present danger.
Shifting from reactive to proactive defense: By focusing on vulnerabilities that attackers are already exploiting, organizations can more effectively cut through the noise of countless theoretical vulnerabilities and target efforts where they will have the most impact.
Providing actionable intelligence: The KEV catalog is not just a list; it provides actionable intelligence to defenders. It serves as a clear signal from a trusted authority that these specific vulnerabilities are being weaponized and require immediate attention.

For federal agencies and — increasingly — for private sector organizations, vulnerabilities listed in the CISA KEV catalog are considered extremely high-priority. Without this particular KEV catalog, organizations may be forced to cross reference several different sources in order to not waste precious resources chasing after every single risk in an increasingly insecure cyber landscape.

What is the EPSS model?

In the ongoing battle to secure complex software supply chains, simply knowing about vulnerabilities (CVEs) and their technical severity (CVSS), or even if they’ve been exploited (KEV), isn’t always enough to make the most informed decisions. Security teams need to understand the likelihood that a newly disclosed vulnerability will be exploited in the near future. This is precisely the gap that the Exploit Prediction Scoring System (EPSS) model aims to fill.

The EPSS is an open, data-driven, and predictive scoring system that estimates the probability of a software vulnerability being exploited in the wild within the next 30 days. Developed by FIRST — the same organization behind CVSS — EPSS provides a crucial layer of intelligence that complements existing vulnerability management tools.

Unlike the CVSS, which scores the severity of a vulnerability’s potential impact, EPSS focuses exclusively on the probability that it will be actively exploited. A vulnerability might have a high CVSS score, but if no one is actually exploiting it, its immediate risk profile might be lower than a medium-CVSS vulnerability that has a high EPSS score.

The EPSS estimate is updated regularly based on the following criteria:

The existence of publicly available exploit code.
Discussions of the vulnerability on social media and dark web forums.
The age of the vulnerability.
The prevalence of the affected software.
Its relationship to other exploited vulnerabilities. This dynamic nature means EPSS scores can change rapidly as new information emerges, reflecting the evolving threat landscape.

A diagram comparing the outcomes of CVSS scores vs. EPSS scores.

Combined with CVEs, a CVSS score, and data from the CISA KEV catalog, the EPSS estimate plays a vital role in an environment where the speed and sophistication of attacks — as seen in supply chain compromises — demand smarter and more efficient resource allocation to secure ever-growing and complex software dependencies.

In other words, security threats contain different facets of vulnerability that together determine the risk they pose and the urgency with which they should be addressed. Once you have decided that the stick down the road is indeed a snake, your next moves are based on your proximity to the snake, whether or not the snake is poisonous, whether or not an antidote exists, and whether or not the snake is an aggressive and deadly rattle snake or a common garter snake that will mostly likely just slither away upon your approach. In moments where quick decisions can be a matter of life or death — or a matter of a quick patch or a security notice to customers — these inputs help form a framework of threat evaluation that can help streamline next steps.

How security contributes to code quality

At a fundamental level, high quality code exhibits the following traits: it is maintainable, it is reliable, and it is secure. With software’s increasing power and complexity, relying on third party components is inevitable. And that’s not a bad thing — in fact, avoiding redundancy is a good coding best practice. However, since you don’t get to review the pull requests that are merged into the code of your dependencies, you need some other method of ensuring that their potential lapses in code quality don’t affect the quality of your code. These days, a robust and intelligent code quality discipline needs to include security considerations such as dependency vulnerability management.

A tool like SonarQube Advanced Security and its Software Composition Analysis (SCA) enables you to not only view all the dependencies within your project, but provides you with a list of dependency risks with holistic scoring and actionable fixes so you can prioritize next steps according to the specific needs of your organization.

In collaboration with Tidelift and its roster of open source maintainers, SonarQube SCA goes beyond public databases of vulnerabilities and provides insights straight from the source. This adds a layer of specialized intelligence that can help reduce the noise often associated with dependency scanning. While the Exploit Prediction Scoring System (EPSS) offers a probability of exploitation, building on the critical “Known Exploited Vulnerabilities” (KEV) catalog, SonarQube SCA further enhances this by integrating real-world maintainer insights, providing an even more refined and actionable understanding of risk. (Because we all know how often we actually look at our Dependabot alerts …)

💡 Want to learn more about SonarQube Software Composition Analysis? Check out a tutorial here.

More resources and references

Read more about coding best practices here.
Read more about best practices for dependency risk management in particular here.
For a breakdown of other top security flaws and how to address them, check out Jonathan Vila’s article on the topic.
Want to learn more about SBOMs? This article provides a comprehensive overview.

Method	Checks that ...
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*
assertRaisesRegex(exc, r, fun, args, *kwds)	fun(args, kwds) raises exc* and the message matches regex r
assertWarns(warn, fun, args, *kwds)	fun(args, kwds) raises warn*
assertWarnsRegex(warn, r, fun, args, *kwds)	fun(args, kwds) raises warn* and the message matches regex r
assertLogs(logger, level)	The with block logs on logger with minimum level
assertNoLogs(logger, level)	The with block does not log on logger with minimum level
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*

DEV Community: Liz

The time I screwed up a conference talk (And the talk on Pydantic I would have given)

Speaking at PyBay

Sometimes you just mess up

Failing gracefully

What I learned about myself

The talk that could have been: Even more about Pydantic

Pydantic under the hood

Real world Pydantic: The Vonage Python SDK

In summary

Seeking validation

Seeking Validation: Data Validation in Python with Pydantic and Vonage Verify

Introduction

What is Duck-typing in Python?

What Are Type Annotations?

Seeking Validation

What is Pydantic?

Core Validation Features of Pydantic

Field Configuration

Serialization

What is a Real-World Use Case of Pydantic?

How the Vonage Python SDK Uses Pydantic Models

What is the Vonage Verify API?

Demonstration: How Does the Verify API Use Pydantic?

Verification By Email

Verification Without Validation: Testing Without Pydantic

In Summary

Further Reading and References

The Vonage Dev Discussion: Everyone loves Pydantic

The Vonage Dev Discussion: How AI is transforming software development

The Vonage Dev Discussion: Defining what an API is

The Vonage Dev Discussion: Making mistakes

The Vonage Dev Discussion: Builder pattern

The Vonage Dev Discussion: Open source

The Vonage Dev Discussion: Music

Don’t Make Assumptions About Assertions: Even with AI you still have to write your unit tests

How to get the most out of this blog post

AI generated code: The key to human productivity or a “disconcerting trend”?

So what can we, as developers, take away from this?

A quick review of unit tests

What is unit testing?

The benefits of unit tests

Unit tests and AI

Writing unit tests doesn’t have to be horrible

The AAAs of testing

Don’t make assumptions about assertions

Getting your hands dirty: Using more precise assert methods to write better unit tests

An artisanal, handcrafted, slow coded Pokemon Flask app

A look at the AI generated unit tests

In conclusion: Unit tests are the human in the loop

Resources and references

A New Era of Code Quality: Beyond bugs and into legal license compliance and risk management

License and litigation and why it’s important to pay attention

The intersection of dependency management, SBOMs, and software licenses

What is an SBOM?

What is dependency license management?

What are the different kinds of software licenses?

How license management contributes to code quality

More resources and references

A New Era of Code Quality: Beyond bugs to supply chain security and dependency health

Weak links: Anatomy of a supply chain attack

First came “vibe coding” …

Now there is “slopsquatting”

The intersection of dependency management, SBOMs and CVEs

What is an SBOM?

What is a CVE?

A stick or a snake: Not every CVE is a threat to your supply chain

What is the CVSS?

What is a KEV?

What is the EPSS model?

How security contributes to code quality

More resources and references