# Boolean Method Symmetry

— Nov 22, 2013

Symmetry is beauty. This applies to lots of things, programming included.

Boolean methods answer a question with “yes” or “no”. To adequately test such a method, you must assert on the positive and negative cases. Chances are you’ll want the complementary method eventually, so let’s start with symmetry and see where it takes us.

## People, be active!

Let’s say we have a `Person` class as follows:

We’re presented with a feature that states a `Person` should be able to report if they are active. Let’s start with a spec:

And now for a very high-value implementation:

Yay! All green :). But, ahem, not exactly feature complete. Alright, so we should probably test the negative case. At this point we’re presented with a choice. Do we test the negative cases of `active?` or introduce the complementary method `inactive?`. We’ll choose symmetry:

Cool, these new specs are erroring with a `NoMethodError`. We’ll implement this complementary method as a function of `active?`:

Nice, we see a properly failing spec. The final implementation is straight forward (althrough if we’re practicing TDD, we may get there in a couple steps):

Alright, so what have we accomplished? We have implemented a simple boolean method along with its complement, and we done this with tests providing adequate coverage for both methods. The complementary method could be argued YAGNI (“You ain’t gonna need it”), but in most cases you’ll end up negating your method. Having a complementary method feels symmetric… and beautiful. Further our specs cover the implementation well without duplication.

## Wrapping up

Symmetry not only looks good, it makes logical sense to client developers and makes your test suite more expressive. When you encounter a boolean method you probably assume its logical complement is defined. Perhaps in this case YAGNI may be set aside for expressiveness.

How do you feel about symmetry? How important is it to the interfaces you define?