So you have written an implementation for that new feature in your Rails app, but your team won’t accept your Pull Request until there are unit tests. What’s more your changes are to private methods of a class. In frustration, you shout, “How do I unit test this code?” The key to unit testing private methods, in any language, is to test them through the public ones. Through almost two decades of practicing test-driven development, and writing unit tests in many languages at several large companies, including GitHub and Pivotal Labs, I have found you have only two strategies for maintainable unit tests around pre-existing private methods.

Maintain shared behavior of multiple implementations by making them pass the same tests. Motivation When building a system, there may emerge a subsystem or class that has to share a baseline set of behavior with other implementations, while providing other non-functional requirements. The shared behavior can be shown to exist by using a contract test. Example Test doubles are a great way to reduce overall speed of the test suite by only running tests against in-memory versions of external services.

I built a small framework, which retaught me why it is important to understand a user’s problem, ship early and iterate. Yes, even for frameworks. It kicked off with a tweet, which expressed disdain for Ruby’s nil. The author yearned for a maybe implementation. Having just finished the Bowling Kata in Elm, a language which has a built-in Maybe type, I decided I could create a quick implementation. I didn’t anticipate how long quick was…

I want to tell you about an alternate design technique, it is called programming by intention. Rather than writing code that describes how to perform some action, you call a function. The interesting thing is the function doesn’t exist. Yet, we are going to call it as if someone wrote it ten minutes ago. We are going to follow a loop of call a function that doesn’t yet exist, implement what it does by calling more functions that don’t exist, until we have to implement the real code.

DRY is commonly interpreted to mean that code should not have duplicate structures. For instance two array indexes that both use rand(4) would be refactored away. Let’s look at an example of code that does exactly that. Person.new(names[rand(4)], jobs[rand(4)]) At some point, this is perceived as duplication and an abstraction is put in place. This abstraction is not logically consistent with the domain logic. Person.new(random_item(names), random_item(jobs)) At first this inconsistency is not inherently dangerous.

In the words of Jimmy Two Times, “I’m gonna go get the papers, get the papers.” The Don’t Repeat Yourself (DRY) Principle is commonly interpreted to mean, code with no duplicate statements. I’d like to explore that thinking with you for a few minutes so that I can demonstrate how it is flawed. I have written a small program that displays the name and job of randomly created people. Take a look at the :random_person function.