Technology Cafe

This is review of the 9th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin

Robert’s love for TDD is legendary and reflects so much in this chapter
He starts with stating the “three laws of TDD”

First Law You may not write production code until you have written a failing unit test.
Second Law You may not write more of a unit test than is sufficient to fail, and not compiling
is failing.
Third Law You may not write more production code than is sufficient to pass the currently
failing test.

If you want to have successful testing strategy based on Test Cases (whether you subscribe to the strict philosophy of TDD or not)- you have to treat test cases with same lover, respect and reverence as Production Code. Keep your test cases as clean as you keep Production code. All rules of cleanliness and Godliness that you apply on Production code are relevant to Test Cases as well.

Well- there are few exception like- you don’t have to kill your self to get the same performance as you would from Production code. (But at the same time- Test cases shouldn’t take too long to run:))

A unit test should ideally test only one concept – this is somewhat like the guideline we use for functions- do one thing alone.

And then you have the F.I.R.S.T rules.

Test should be Fast

Tests should not depend upon each other.

Tests should be repeatable in any environment

Test should have a boolean value- Pass or Fail

And they should be written in Timely fashion.

For review of other chapters- please see this post.

This is review of the 7th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

Exceptions are a way of life . You can hide but not escape.
But you can handle the possibility of an error in way so that you can make your life easier.

Use Exceptions rather than Error Codes. Using error codes intermingles your normal flow with the error flow and you are forced to handle the error immediately. With Exceptions- you can procrastinate the handling to a later point in the flow and also keeps your normal flow and error flow in separate drawers- neatly.

When catching exceptions- you have the opportunity to capture more information about the error. e.g. you can capture the offending SQL or maybe the arguments of the method which could be responsible for the error.

On classifications of exceptions- think about the caller. Is the caller going to handle the two types of error differently or the same way? If it is going to handle in a different way- you then may need two different exceptions- else one would suffice.

For review of other chapters- please see this post.