The first “barrier to entry” for doing emergent design, an advanced developer practice for incrementally building software, is to understand object-oriented design and development. In theory, the object-oriented model should be easy to understand but I don’t often see it well-understood in industry. I’ve reviewed millions of lines of code from companies across a range …
Continue reading “Understand Object-Oriented Design”
Read MoreBy now you’ve probably figured out that I am a weirdo and that I like doing things differently than other people. In fact, I am an advocate of doing things backward. But I’m not being random here. As it turns out, the way most people build software includes some of the worst inefficiencies that I …
Continue reading “Why Practice Eight: Implement the Design Last”
Read MoreI discussed many benefits of using test-first development over these last eight blog posts. I find many benefits to doing test-first development but one stands out to me to be the biggest benefit and that is that the tests that I write concretize abstract requirements. This makes requirements understandable because they are real and tangible …
Continue reading “Use Accurate Examples”
Read MoreThe number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code. I am a big advocate of having a complete …
Continue reading “Avoid Over-Specifying Tests”
Read MoreUnit testing frameworks are simple but I find them highly valuable. They contain a collection of assertions that I can use to validate a range of values and behaviors in the code that I’m building. I use assertions to verify that values are within bounds, exceptions are called when expected and not called when unexpected, …
Continue reading “Use Mocks to Test Workflows”
Read MoreOne of the keys to doing test-first development successfully and having the tests that you create to support you in refactoring code rather than breaking when you refactor code, is to write tests against the behaviors you want to create rather than how you implement those behaviors. This is an important insight but not always …
Continue reading “Test Behaviors, Not Implementations”
Read MoreAnother aspect of using unit tests as specifications is to clearly show what’s important in each test. We do this primarily by naming things well and calling out generalizations and key concepts in the names of the symbols that we use. Every test has a name but you never call it, the system calls it …
Continue reading “Show What’s Important”
Read More