Twelve-year-old blog posts 🕰️

Inspired by fellow blogger Lars-Christian, I decided to import posts from an old blog of mine.¹

The posts are mostly from 2012 and deal with software design and testing. While my thinking has obviously evolved during these years, I think they are pretty good. Feel free to scroll through. 😊

Software design #

A series of posts that discussed how to separate logical complexity from dependencies in order to improve the design and make it more maintainable. These were early attempts to express the ideas that ultimately became functional foundations.

• How unit testing changes your design
  Most complexity should be in classes with few dependencies, and most dependencies should be in classes with little complexity.
• Extract the logic (what’s left is glue)
  To make code easier to understand and test, try to move complex logic away from code with many dependencies.
• Moving logic and data together [example]
  An example of how moving logic and data together can result in a better design.

And a few other posts covering various topics related to software design.

• What, how, and why?
  Let the method signature describe “what”, the body “how”, and the caller “why”.
• Realize a vision, not a requirement spec
  Are you improving the system or just extending it?
• Convert guard clauses to value objects
  How replacing validation functions with types can make your code safer and more expressive.

Unit testing #

The other large topic was how to write good (unit) tests.

Some were more practically focused.

• How to unit test code calling a static method
  Don’t try to test code which calls static methods, try to get rid of the static methods.
• Don’t test private methods
  The need to test a private method often indicates a new class waiting to get out.
• How to write robust tests
  Concrete tips on how to write robust tests that survive a refactoring.

Others were a bit more theoretical.

• Tell me what to expect
  When naming tests, include both the input as well as the expected outcome.
• Find each bug once
  For every bug you fix there should be an automated test which will fail if the bug reappears.
• See tests as living documentation
  A few examples of how viewing tests as documentation can affect your test writing.