Capitalizing on Pydantic Data Validation With Embedded Unit Tests

In my previous blog post, I suggested a balanced approach to promote code quality, which does not only rely on unit tests, but also utilizes runtime data validation using the Pydantic library.

Now listen up everybody, this article is not meant to challenge unit test centric approaches in collaborative projects with multiple team members. You may like to check out my previous blog article to read more about my thoughts related to that matter.

On the contrary, I want to playfully study an alternative approach here that you might like to consider in your personal hobby projects to become more productive.

Now that I have made it clear that I am not trying to influence collaborative projects, I hope that I can safely proceed to examine an ideology that aims to avoid writing extensive unit tests in your personal projects in favour of a prototyping style coding technique. In this approach, however, unit tests are not completely abandoned, but rather they take on a demonstrative nature.

In accordance with that idea, unit tests do not aim to cover all possible error scenarios, but their task is to serve as an example of how the function under test is intended to be used.

The wariness regarding the coverage of unit tests comes from the empirical observation that in active development, the developer’s vision of how the software’s internal logic should work fluctuates. Thus, the coding event is part of the thought process. A dogmatic test-oriented way of thinking is not too suitable for such a dynamic process. If the lifetime of a function is only days and hours, it is certainly frustrating to spend ten times the time to write all kinds of tests for a function that, however, changes decisively or is removed completely in the next moment.

Furthermore, writing and modifying unit tests is made more difficult if they are separate structures from the code being tested. In the worst case, they are placed in a completely separate directory structure that mirrors the directory structure of the actual code, creating its own ghost hierarchy.

It is somewhat easier if the test files are placed side by side with the code files. In this case, it is easier to see which files are completely missing tests. It’s also easier to find the tests just by looking in the code files folder.

An even more radical approach is to place the tests entirely inside the code structures, as part of the tested classes themselves. But why not? This approach can be perfectly valid. In this case, it is easier to change the tests together with the code.

I want to reduce the extensiveness of the tests and emphasize their demonstrative use, in which case runtime data validation will play a more central role in ensuring the safety of the code.

A Simple Code Example

Isn’t it annoying that many bloggers in 2025 still don’t know how to put capital letters right in their titles? If you notice awkward grammar and other rule mistakes in the writing, it somehow reduces the credibility of the article. However, for many non-native English speakers (like me), this is a common problem. Let’s fix this programmatically!

Here’s a class written in Python that correctly capitalizes titles:

from titlecase import titlecase

class CapitalizedTitle(BaseModel):

    value: str

    @classmethod
    def from_text(cls, text: str) -> 'CapitalizedTitle':
        titlecase_name = titlecase(text.strip())
        return cls(value=titlecase_name)

Write a method that allows you to ask the Title object to give an example instance of itself… Just out of curiosity to see what you are going to get:

@classmethod
def get_sample(cls) -> 'CapitalizedTitle':
    return cls.from_text('capitalizing on pydantic data validation with embedded unit tests')

And finally, embed a simple unit test in your CapitalizedTitle class to verify that it fixes the cases in your titles as expected:

@classmethod
def test(cls):
    t = unittest.TestCase()
    t.assertEqual(cls.get_sample().value, 'Capitalizing on Pydantic Data Validation With Embedded Unit Tests')

See also the complete code of Title class example:

from pydantic import BaseModel
from titlecase import titlecase
import unittest

class CapitalizedTitle(BaseModel):

    value: str

    @classmethod
    def from_text(cls, text: str) -> 'CapitalizedTitle':
        titlecase_name = titlecase(text.strip())
        return cls(value=titlecase_name)

    @classmethod
    def get_sample(cls) -> 'CapitalizedTitle':
        return cls.from_text('capitalizing on pydantic data validation with embedded unit tests')

    @classmethod
    def test(cls):
        t = unittest.TestCase()
        t.assertEqual(cls.get_sample().value, 'Capitalizing on Pydantic Data Validation With Embedded Unit Tests')

But still, wouldn’t it be great if you could run all your unit tests in an all-covering test suite? No problem!

class TestSuite:

    @staticmethod
    def run():
        CapitalizedTitle.test()
        # Add all other unit tests here

That’s all for now. Talk to you then!