Entrait 0.4 — loosely coupled application design made easy

In my experience business languages that you mention as reference in your post are always PITA to work with and on of the big reasons is this "industry best practice" with DIing everything, everywhere, all the time, and trying to write tons of tiny unit-tests for every class/method.

This whole "unit-testing" everything is huge waste of time, where people oftentime test most banal implementation details or just mocks themselves, making the code extreme drag to refactor and evolve.

More systems oriented software is getting by perfectly without so much (or at all) with great results for a reason. Part of it is only ever mocking big parts dealing with side-effects/IO and implementing as much as possible in a side-effect free manner (so you there's no need to mock anything) and more higher level (e2e/integration) testing, or decoupling parts of the system into message-passing (channels actor-like parts).

I highly recommend: 🚀 TDD, Where Did It All Go Wrong (Ian Cooper) - YouTube which 100% matches my experiences with JVM-enterprise-app software.

I mentioned is kind of off-topic, since I happened to read through this blog you posted and give you my perspective. Generally in Rust I need DI to to decouple the most inconvenient external components.

1 Like

Absolutely, I need DI mostly to mock out database calls and other exernal services. Maybe also decoupling the external interfaces of my applications (e.g. web APIs) from the underlying logic if I want some simple request/response tests.

When I do need to write a regression test for some reason or another, it'll feel nice to have a decoupled architecture in place from the start. It doesn't mean we have to over-use it. The rust-realworld-entrait app is for demonstration purposes, I hope I never spend time on useless tests in real life :slight_smile: Only things that are non-trivial - I often work with non-trivial domains.

1 Like

Excellent TDD talk :+1:

I've released entrait 0.4.3 with support for modules. Curious to know how it feels to use. I'll try to fit that pattern into the realworld app soon.

I just released entrait 0.4.4 which has support for internal inverted dependencies. Upstream crates are now able call downstream crates without losing track of the Impl<T> type. This means that dependent/downstream crates can properly extend the application, so that "onion"/"ports-and-adapters"-like architectures can be designed with relative ease.

I've made an example app which demonstrates the architecture possibilities: rust-realworld-entrait.