Reflections on TDD and Software Design – Part 2
In part 1 I talked about the key aspects of my TDD practice from a workflow pov, in this final part I will talk about the more tricky aspects of TDD – scope and design.
blatherings on software…
In part 1 I talked about the key aspects of my TDD practice from a workflow pov, in this final part I will talk about the more tricky aspects of TDD – scope and design.
Having recently completed several weeks of pairing with a junior engineer on one of my teams, I came away with some reflections on the practice of TDD and its effect on design that I want to share.
I will attempt to define each element of the style a bit and also show some C# code examples to illustrate the points
Deliberate and thoughtful architectural decisions that solve real business problems and mitigate enough of the real risks, is the RIGHT and the MIDDLE PATH way to go.
Given the fact that there is no shortage of SPA frameworks and libraries like Angular, React, Vue, Knockout ad inifitum, for building the new frontend app for my app, I decided to go with Blazor.
I have a personal expense tracking app that for the last few months I’d been working to migrate away from MVC towards more modern client apps whilst reusing the backend code and logic.
A few weeks ago I came across this Mars Rover programming challenge/kata and being a bit of a space buff, I thought I will take a crack at it.
In this post I will share some of the TDD heuristics that I have found useful on when you should use mocking to verify interactions and when should you resort to state verification.
Many articles talk about the what of this style but in my view, not enough talk about the how. In this post, I am going to try and show one way to actually structure the solution to be more in line with the hexagonal ports and adapters style.