DEV Community: Liz Acosta

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

Liz Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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 Acosta — 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.

Passing the Vibe Check: Navigating the changing development landscape

Liz Acosta — Fri, 16 May 2025 16:50:04 +0000

In February 2025, OpenAI researcher Andrej Karpathy coined the term “vibe coding” on social media. In his post, he described his process for developing a small project — without ever writing any code of his own.

The inception of the term “vibe coding.

To build his “amusing throwaway weekend project,” Karpathy didn’t even need to touch a keyboard. He used superwhisper, an AI-powered voice to text transcriptor, to dictate application requirements to Cursor Composer. Cursor Composer, the AI-powered multi-file code editor and application generator, then translated the dictated instructions into a complete web app. Karpathy adjusted the app with the “dumbest” prompts like “decrease the padding on the sidebar by half” and accepted the changes without reviewing the diffs. When Karpathy encountered an issue that Cursor couldn’t fix, the OpenAI co-founder would just “ask for random changes” until the bug went away.

“It’s not really coding,” he admitted, “I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.” (Emphasis mine.)

Look ma — no typing! A diagram of Karpathy’s vibe coding stack.

But the vibes were anything but good for Leonel Acevedo, CEO of EnrichLead. In March 2025, he posted on social media about the SaaS application he’d built with “zero hand written code,” concluding that everyone else could “continue to whine about it [AI] or start building.” This use of AI contrasts with Karpathy’s “throwaway” project as Acevedo was touting a production-ready SaaS application and implying a different level of robustness and real-world applicability.

Just a few days later, Acevedo posted that EnrichLead was under attack with “random things happening” such as maxed-out API keys, bypassed subscriptions, and corrupted databases. Because Acevedo isn’t technical, it took him longer than he anticipated to debug the code. Eventually he discovered that his vibed code exposed important API keys, making his app vulnerable to attack.

The worst kind of live debugging ever.

Accidentally pushing a hardcoded secret can be seen as a rite of passage for developers. This mistake is so common that GitHub has automatic alerting, and remediation for unintentionally publicized keys and tokens; at Sonar, we shifted that check further left by highlighting potential vulnerabilities right in your IDE. With the advent of “vibe coding,” incidents like the one EnrichLead experienced are likely to become more common. While it’s too soon to say if vibe coding will persist, one thing we know for sure is that AI-generated code is here and it’s here to stay.

And it’s just another iteration of the continuously evolving software development lifecycle.

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

What is vibe coding?: A definition of vibe coding along with the associated tools, benefits, and disadvantages
To vibe or not to vibe?: Surviving AI as a developer
More than just vibes: How AI can help us become better developers
Try it yourself: Tools and resources for surviving vibe coding

What is vibe coding?

Vibe coding — or if you prefer a less cringey name, “AI coding” — is “an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding.” Vibe coding relies exclusively on LLMs to interpret requirements and generate entire applications accordingly.

What tools are used for vibe coding?

The most popular vibe coding tools at the moment are Cursor and Windsurf. Both IDEs use Claude 3.5 Sonnet under the AI hood, but with different features and user experiences.

Cursor and Windsurf use the same LLM under the hood, but each IDE has its own vibes.

What are the benefits of vibe coding?

Lower cost of entry: No coding knowledge, no problem! If you’ve got a good, well thought-out idea and can write a decent prompt, the code itself is no longer an obstacle.
Higher development velocity: When you can let the IDE handle all of the code, prototyping and iteration cycles become quicker and easier.
More room for complex and innovative problem solving: With the burden of writing boilerplate, class setups, basic CRUD operations, and other tedious tasks lifted, developers are free to focus on more high-level logic.
A bridge for knowledge gaps: Even the most experienced developer faces the challenges of learning new technology — AI coding can facilitate quicker onboarding by supplying the fundamentals.

Prompting Cursor to generate a Pokédex Flask app …

… and it worked!

What are the disadvantages of vibe coding?

Lack of consistency and predictability: It is important to remember that the output of LLMs is not deterministic. This can lead to a codebase with varying styles, structures, and approaches, rendering the code harder to understand, maintain, and debug predictably.
An increased vector of bugs, errors, and security vulnerabilities: Because AI doesn’t actually “know” anything, a prompt may generate code with issues that a more experienced developer would know to avoid.
Challenges in long-term maintainability and scalability: Without any context, an LLM may produce code that is inconsistent and with no consideration for future optimization.
Less developer productivity: AI-generated code may not be well documented, increasing developer toil while trying to refactor, debug, or extend code. Moreover, trying to refine a prompt for a more desired outcome could take more time than just writing the code manually.

The problem with vibes: You probably know better than to include all your styling in your HTML template file … but AI doesn’t!

To vibe or not to vibe? Surviving AI as a software developer

The software development lifecycle (SDLC) refers to a structured process for designing and building software. It is a rapidly evolving landscape wherein each iteration the role of the developer changes and adapts to address the latest challenges in software engineering.

In the earliest “code-and-fix” era, the developer was a lone coder, directly addressing issues as they arose with little formal process. The advent of the Waterfall model transformed the developer into a specialist within a linear process, focusing on specific stages like coding or testing after requirements were defined. Iterative and incremental models then required the developer to become more adaptable, working in smaller cycles and integrating feedback more frequently.

The rise of object-oriented methodologies shifted the developer towards architect and component builder, emphasizing modularity and reusability. The Agile revolution demanded the developer become a collaborative team member, engaging in frequent communication, adapting to changing requirements, and participating in all stages of the sprint. Finally, the Lean and DevOps era positions the developer as an integrated part of the entire delivery pipeline, involved in automation, deployment, and operations, with a broader responsibility for efficiency and reliability.

AI coding signals a new horizon for SDLC, and with that new day comes new opportunities for developers — as long as we’re prepared for them.

The only const is = “change”: The evolution of the software development lifecycle.

The evolution of the developer

By understanding the benefits and disadvantages of AI, you will be better equipped to continue to grow as a developer. After all — you are a developer. You’re smart and learning new technologies is what you do best.

Familiarize yourself with AI coding tools for developers. Whether you call it “vibe coding” or “AI coding,” check out the different tools people are using. There’s nothing quite like hands-on experience to learn something new.
Vibe, but verify. Get into a good practice of double-checking the AI’s work. With AI doing most of the heavy lifting, your job is more about diligently overseeing and reviewing the code rather than manually composing it. Employing a code quality tool like SonarQube could have prevented EnrichLead’s secret exposure.
Embrace the opportunity to think more systematically. With AI handling all the nitty-gritty, you can focus more on solving more complex problems with more innovative solutions. You are more free to be an architect without having to be an expert on each component.
Learn how to refine your prompts. LLMs like Claude respond better to clear, concise prompts that explicitly outline what is being requested and what the expected output is. Thinking more strategically about what your requirements are, what kind of design pattern you want to follow, how you are going to test your code, and how you are going to deploy and maintain it will help inform and improve your prompting.

💡 How could you formulate a prompt to avoid exposing secrets? What requirements or parameters would you include?

More than just vibes: How AI can help us become better developers

Waterfall, Agile, ad-hoc, DevOps, vibe coding — no matter what SDLC or tools we are using, as developers, we are concerned with efficiency, optimization, reliability, and maintainability. We want to make software that is useful and we don’t want to get paged in the middle of the night for an incident. AI can be a valuable tool that helps remove some of the more tedious tasks associated with development and free us to think more creatively; the potential disadvantages of AI mean we have the opportunity to be more deliberate and intentional in our work.

While we can’t predict exactly how AI will affect the software development lifecycle, we do know that no matter what direction it takes, code quality and security will always be central to meaningful, robust, and reliable software.

Just ask the guy at EnrichLead.

Try it yourself: Tools and resources for surviving vibe coding

For all you Java developers out there, Sonar developer advocate Jonathan Vila has posts on Java and code quality here.
Interested in learning more about how Sonar can help you vibe better? Check out this tutorial.
Still feeling a little AI anxiety? This article by UX Collective’s Pete Sena might help alleviate that.
Whether we like it or not, AI is (probably) here to stay, so now’s a good time to start developing some good AI coding habits.
No matter what, best practices will always be in style.

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 Acosta

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

Passing the Vibe Check: Navigating the changing development landscape

What is vibe coding?

What tools are used for vibe coding?

What are the benefits of vibe coding?

What are the disadvantages of vibe coding?

To vibe or not to vibe? Surviving AI as a software developer

The evolution of the developer

More than just vibes: How AI can help us become better developers

Try it yourself: Tools and resources for surviving vibe coding