(If you haven’t read or completed part 1 yet, click here: https://agileforall.com/the-password-strength-checker-design-kata-part-1/ )
How often did you have to go back to an existing test and change the password string?
No big deal, right? It wasn’t that hard. Recall, however, that this is a microcosm: That need to go back and revisit existing tests
In two of my three technical courses (Essential Agile Engineering Skills and Essential Test-Driven Development), the first major topic I cover is refactoring, its role on an Agile software development team, and its role in software design.
Sometimes, but not always, the participants have the time and inclination to come back to the topic of software design.
Readers! Subscribers! “Followers”! I hope you are all healthy and safe.
What is “Technical Debt”?
People are still debating over the one true meaning of the term “technical debt.” It was coined by Ward Cunningham around 2009, and the short definition is this:
Technical Debt is the deferment of good software design for the sake
Nope, I haven’t forgotten that my next newsletter was going to be in response to a comment on the last newsletter. But I’ve discovered the need for some diagrams, or code, or something other than prose, to explain myself succinctly. So, it’s taking longer than
A client recently asked me if a unit test could test multiple objects. On the surface, you might suppose my immediate answer would be “No way!” But his question, and my answer were both a bit more nuanced than
From the Developer Essentials Newsletter: The intersection of Agile methods and technical software development.
An editor of Dr. Dobbs magazine once wrote to me—replying to my response to an article—“All the benefits [of Test-Driven Development] could be attained equally by writing tests after the code, rather than before.”
Tests exercise software to be sure it’s doing what was intended. So, whether you use Test-Driven Development (TDD) or write unit-tests