tarball.tar.gz

POSTGRES_USER

POSTGRES_PASSWORD

POSTGRES_HOSTNAME

APPLICATION_DB

POSTGRES_PORT

POSTGRES_DB

Python Execution

Flask

Flask + Postgres

Python Test

Clean architecture is a software design methodology that separates the processes of an application into discrete steps instead of presenting them as “spaghetti code.” With the versatility of Python, software engineers can build performant, modular applications quickly using the Flask framework.

This course will help you build better applications using the principles of clean architecture. You’ll start with an introduction to data flow in clean systems and learn about the advantages of layered architectures. Next, you’ll learn system components and the connections between application layers. You’ll then design and build a clean system using Python by layering components in guided coding exercises. Finally, you’ll learn how to add functional components for the web, handle errors, and work with external databases using both Postgres and MongoDB. At each step, you’ll use test-driven development practices to ensure robust functionality.

Clean Architecture in Python

At this point, we can create real tests in the `test_postgresrepo.py` file and replace our `test_dummy` function. All tests receive the `app_configuration`, `pg_session`, and `pg_test_data` fixtures. The first fixture allows us to initialize the `PostgresRepo` class with the proper parameters. The second fixture creates the database with our test data. Finally, the third fixture contains the database.

## Impact on our test cases

The tests for this repository are a copy of the ones we created for our `MemRepo` repository. This is not surprising. Usually, we want to test the very same conditions, regardless of the storage system we are currently using. However, toward the end of this chapter, we’ll see that, while these files are initially the same, they can evolve differently. This can be due to the occurrence of bugs or corner cases resulting from specific implementations, such as in-memory storage, PostgreSQL, etc.

At this point, we can create real tests in the `test_postgresrepo.py` file and replace our `test_dummy` function. All tests receive the `app_configuration`, `pg_session`, and `pg_test_data` fixtures. The first fixture allows us to initialize the `PostgresRepo` class with the proper parameters. The second fixture creates the database with our test data. Finally, the third fixture contains the database.

# Impact on our test cases

The tests for this repository are a copy of the ones we created for our `MemRepo` repository. This is not surprising. Usually, we want to test the very same conditions, regardless of the storage system we are currently using. However, toward the end of this chapter, we’ll see that, while these files are initially the same, they can evolve differently. This can be due to the occurrence of bugs or corner cases resulting from specific implementations, such as in-memory storage, PostgreSQL, etc.

Let’s learn about how to use PostgreSQL as a repository and test it.

Get Started

A Day in the Life of a Clean System

Components of Clean Architecture

A Simple Coding Example

Add a Web Application

Error Management

Integration with a Real External System Postgres

Integration with a Real External System MongoDB

Run a Production-ready System

Appendix

Integration Tests

Impact on our test cases