Tag System Design

In the last article, we wrote a few tests for a project to make sure that our refactoring won’t break anything. To understand the project better, we will separate the part of the domain and add a test to it. This will make the test more authentic.

There is a problem with the end-to-end (e2e) tests: database under the hood. This attitude is not carefree. Firstly, those tests are rather slow. It might be an issue when the number of tests will increase. We use a real database connection that has an overhead.

When we talk about software design we very often use very generic and abstract words. But, how about the practice? How does it look in a real-world project? Today, you and I will start refactoring a small to-do app for better testability and maintainability. In this article, we will make the application testable. We’ll write black-box tests that will prevent from some bugs and make future refactoring easier and safer.

When I started my career as a software developer and published the first production application what I did was staring at logs and look for some fatal errors. It was a monolith application. Every log saying that something’s wrong had to be fixed. ASAP. This approach worked for some time. However, when the scale increased, and I started building microservices, I couldn’t get rid of all of them. Network issues, database failures, and more - it happens all the time.