There have been many C/C++ unit testing tools over the years, from CppUnit and CppTestKit (which seems to have disappeared from the web) to Google Test and CppUTest. I’ve tried many of these, but not all of them.

In Design Patterns, the Gang of Four describe the Template Method pattern. In this pattern, a base class method describes the structure of an algorithm or process and calls other methods for the steps. The base class can either force subclasses to implement the step methods or it can contain a default implementation that subclasses can choose to override if necessary.

In Smalltalk Best Practice Patterns, Kent Beck describes a pattern called ComposedMethod. The basic idea is that a program should be divided into methods that each perform one identifiable task. Each method should be written so that its operations are all at the same level of abstraction. This is a very good pattern, and well worth using.

I’m thrilled to announce that I’ll be speaking at the Golden Gate Ruby Conference 2014 (GoGaRuCo), September 19-20 in San Francisco. I’ll be presenting “Gilding the Rose: Refactoring Legacy Code”, where I’ll show how to use tiny refactoring steps to tame legacy code.

When designing base classes, there are a number of guidelines and patterns that can impact the design. One of those is the idea of “hubs”. Thanks to my wife for the inspiration on the name.

A common piece of advice in the test-driven development (TDD) community is to limit yourself to one assertion per test (OAPT). Others disagree, finding the guideline too restrictive and dogmatic. Still others propose a compromise: you can have more than one assertion in a test, but they must all be checking related aspects of the same outcome.

As I discussed about a year ago, Smalltalk’s argument-passing syntax is somewhat limited compared to other languages when you want to define a flexible API. By “flexible”, I mean an API where some parameters are optional with reasonable defaults, and the order of the parameters can vary. When it comes to “constructor” methods, there is another option.

If you practice Test-Driven Development (TDD) or Behavior-Driven Development (BDD), you may be familiar with the Arrange, Act, Assert pattern.

As programmers, we’re taught to avoid hard-coded (“magic”) numbers in code. Instead, we replace them with constants or some other kind of named value. This is good advice, and helps with the understanding of our code. Also, if one of these magic numbers needs to change in the future, we can make the change in one place. This is a relatively basic rule.

This post is part of a periodic series about The Tools I Use.