Getting Feedback from Test-Driven Development and Testing in Production

"Hast mentioned that they trust their unit tests and integration tests individually, and all of them together as a whole. They have no end-to-end tests: We achieved this by using good separation of concerns, modularity, abstraction, low coupling, and high cohesion. These mechanisms go hand in hand with TDD and pair programming. The result is a better domain-driven design with high code quality. Previously, they had more HTTP application integration tests that tested the whole app, but they have moved away from this (or just have some happy cases) to more focused tests that have shorter feedback loops, Hast mentioned."

"Since test environments will always be an approximation of production, and usually struggle with long supply chains and bad test data, they have more or less stopped using them in their entirety, Mjölne Söderbom explained: We prefer to test in production since that is where we get the feedback with the best quality. They reduce risks by putting new features behind toggles and deploying small pieces at a time. It is something they have done for several years now, and it works really well, Mjölne Söderbom said. If something breaks in production, it's easy to find, fix, and roll back/forward, he added."

Teams trust unit and integration tests individually and collectively and have removed end-to-end tests. Good separation of concerns, modularity, abstraction, low coupling, and high cohesion support this testing strategy. TDD and pair programming reinforce design quality and domain-driven design while enabling short feedback loops. Test environments are regarded as imperfect approximations of production, so testing often occurs in production for higher-quality feedback. New features are deployed behind toggles and released in small increments to reduce risk and simplify rollback or fixes. Pair and mob programming eliminates solo tasks and separate code reviews to share knowledge and improve quality.

Read at InfoQ