Journey to TDD - Code Style

If you found this article and want to start at the beginning, this series starts here.

I got my first job after learning testing and spent most of my time writing tests, then code, and refactoring.

Ever get into a discussion over code style, such as:

if a
  return b
else
  return c

There may be a comment to re-write the above to:

a ? b : c

Which is better or worse? Ultimately, it comes down to two point of view: readability or optimization. This can happen not just to the above, but any piece of code.

This argument is a good exercise in communication between developers and improves the code base. At the same time, becomes tiresome when repeated.

One thing I realized when a code base is well tested: when you write tests in a clear manner, you can write code however you want because the tests cover the code!

Is the code readable? Win-win. Is the code terse? The tests explain what’s going on. Win.

The key is having tests simple and passing, the code can be as terse as the team wants it to be. Isn’t that a great win to TDD even more?

As I found out, tests are not always important.