I’ll propose a testing strategy for the hexagonal architecture. — Hexagonal architecture The hexagonal architecture and the clean architecture are domain-centric architectural patterns. They’re powerful and adaptable to your needs; even simple apps like command-line tools benefit from centralizing the domain (to separate the I/O from the actual algorithm). Here’s what you need to know: Your app (a bounded context) is comprised…

One of the goals of automated testing is to support you while refactoring, which is a continuous task. Tests should not be in the way. Let’s see how. — 📝 I’ll use the Arrange; Act; Assert terms (the same as Given; When; Then), which is the way tests should be split. A flawed strategy I often see codebases that rely on low-level unit tests to test everything; there are just a few high-level tests for happy cases. I think this derives from…

One of the goals of automated testing is to support refactoring but many times, they get in the way. Tests should aim to define what is intended (behavior); not how it’s implemented (details). — Refactoring is a continuous task so we should reduce the exposure to details. Also, tests should not hold us back when evolving the architecture. A good test suite enables coding to be fun. Write your tests in such a way that as many implementation details as possible could be changed…

Changing interfaces (e.g. API web handlers, queue event handlers, web pages) is common and can impact many tests. How can we decouple them from those changes? — Ideally, when refactoring, we don’t want to update any tests. Besides the refactoring pain, think about the verbosity of making HTTP calls or resorting to HTML page selectors in the tests. Also, consider the negative impact on tests acting as documentation (one of the testing goals).

I’ve been using Python for a year in production apps. This is the list of things that made that path harder. — This is not a language-bashing article but rather a heads-up regarding some issues that may surprise newcomers like me. The issues range from small inconveniences to questionable design decisions. Be aware this is written from the perspective of a one-year-old learner coming from other languages while keeping an open mind…

DI ensures that components have their dependencies available without knowing having to create them. A dependency is another component that focuses on a specific need (e.g. database, third-party API, clock, etc.). — Why do I need DI? DI enables the easy replaceability of dependencies — these should behave as plugins. Here’s why that matters: You insolate non-pure calls like getting the system clock or using an id. random generator — in testing, you can easily inject test doubles thus granting determinism;