Bob Martin’s Clean Code: A Handbook of Agile Software Craftsmanship is finally out and the UPS man just dropped a shiny new copy on my doorstep. It kicks off with these fine words of wisdom:

"The only valid measurement of code quality: WTFs/minute"

Thought I’d take you with me on my quick skim in case your UPS man wasn’t as nice…

Chapter 1 begins with "You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers." Includes sections like The Total Cost of Owning a Mess.

The Functions chapter earns bonus points for its opening image of the hookah-smoking caterpillar from Alice in Wonderland. I’m not quite sure what Uncle Bob is suggesting here, but this chapter includes goodness to the likes of Have no side effects, Prefer exceptions to returning error codes, and classic Uncle Bobness such as:

"Functions should do one thing. They should do it well. They should do it only."

The Formatting chapter explains how to avoid "a scrambled mass of code that looks like it was written by a bevy of drunken sailors" (hmm, I think I’ve seen that code before). And the Objects and Data Structures chapter (which starts with an image of Data from Star Trek – I swear I couldn’t make this stuff up) has some interesting looking sections like Data/object anti-symmetry, The law of Demeter, and Train wrecks.

Read More…..

As the unit testing debates continue on my project, I can’t help but noticing that people are spending all sorts of time pontificating over the right way to unit test, without stepping back to consider what they’re trying to achieve with unit testing. And because they don’t know where they’re going, they’re not able to reach any conclusions on how to get there. Sound familiar?

There are actually a number of fabulous reasons for doing unit testing:

1. They help us think about our design in a way that we might not otherwise.
2. They lead to cleaner code because it’s often easier to re-factor our code to be more testable then it is to write unit tests that exercise obfuscated or otherwise hard to access code.
3. They validate that our modules are behaving correctly.
4. They provide a safety net to ensure our existing modules continue to function properly as our application evolves.

These aren’t all intuitive and so a lot of people will only consider #3 when they think about unit testing. And yet, what’s interesting is that #3 typically provides the smallest return on our unit testing investment because we tend to find WAY more defects through #1 and #2 as we work out how to develop our tests, and then of course in #4 as we continue to change our code over the application’s lifetime. And, unfortunately, by focusing only on #3, it can lead us to make some faulty decisions when we try to reason about the best way to do unit tests.

Read More…..

Software development gurus Bob Martin and Jim Coplien go head to head on the virtues (or lack thereof) of Test-Driven Development.

And in this corner, we have Robert "Uncle Bob" Martin, who throws the first punch with the bold: "it has become infeasible for a software developer to consider himself professional if he does not practice test driven development."

In corner #2, wearing the I [iterate] scrum shirt, we have Jim "TDD will deteriorate your design" Coplien, who hits back with Design By Contract.

In this 20 minute bout, which InfoQ caught on video, Bob Martin explains that "nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test" and proposes his 3 Laws of TDD to address this:

Read More…..

There is a hot debate on my project about whether or not our JUnit tests are pure unit tests. What the heck does that mean, pure unit tests? Our tests are JUnit tests. Doesn’t that, by definition, make them unit tests?

Actually, no. Unit testing does actually refer to a very specific type of test – one whose sole purpose in life is to:

In other words, a unit test should only test an individual unit (a class or a method). If executing a test crosses that class’s boundaries to say, access the database or call a method in another class, you’re no longer doing unit testing, you’re doing integration testing.

Okay, that’s really nice and now I can feel like a big, important software engineer for knowing the true definition of unit test. But, why do I care?

Read More…..