Unlocking the Power of Test-Driven Development: Lessons from Instant Feedback and Domain-driven Design

One of the easiest ways to motivate yourself to do Test Driven Development is to remember the times

– When you played the role of UI developer and loved the instant feedback that browsers gave for your HTML, CSS, JS, TypeScript code
– When you prepared for coding interviews using AlgoExpert or CodeSignal and loved the instant feedback from running test cases against your algorithm
– When you played the role of a DataModeler, using tools like DBeaver or NocoDB, and loved the ability to run some queries against the data model and see if they are easy or tough to reason and write.

Note :
– Choose your architecture to be “Data Driven Architecture” – plumbing in your system should allow “Data flows” to happen with minimal friction, highest security and governance, optimal SLI, SLO and therefore SLAs
– Choose your design to be “Domain Driven Design” – your system should speak the domain language to all its stakeholders. Your data model should be understandable/presentable to anyone inside/outside organization.
– Choose your development to be “Test Driven Development” – your algorithms should satisfy the acceptance criteria and therefore the definition of done.
– Remember skills needed for thinking and designing test cases are different from those needed to build the algorithms that satisfy those test cases. BDD tools like cucumber can help other team members contribute.

This post was later published on LinkedIn here.