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.

A colleague and I recently had to track down a tricky bug in our system, and I thought the story might be interesting.

I recently released SuffixConditionals for Visualworks Smalltalk. In the release announcement I said:

Smalltalk collections have a rich protocol for enumerating their elements: simple iteration with do:, mapping with collect:, filtering with select: and reject:, reducing with fold: and inject:into:, and more.

The video of my Mountain West Ruby Conference talk, Affordances in Programming Languages, is now up on Confreaks. I hope you enjoy it!

I’ve always been fascinated with the way conditionals are implemented in Smalltalk. Rather than having built-in if/then/else keywords, Smalltalk uses polymorphism. The Boolean subclasses True and False simply implement #ifTrue:, #ifFalse:, #ifTrue:ifFalse:, #and:, #or:, etc. appropriately for themselves. This is a brilliant design, and understanding it got me closer to really understanding Smalltalk.