Unit Testing - Cheat Sheet

This page has been written just to summarize the key statements around unit testing learnt from the book - Effective Unit Testing - a guide for Java developers.

It should act as a refresher (at least for me) whenever the page is skimmed through.

Tests help us,

• catch mistakes
• shape our design to actual use
• avoid gold-plating by being explicit about what the required behavior is.

The biggest value of writing a test lies not in the resulting test case but what we learning from writing it.

Clean Code - Cheat sheet

Pretty impressed after going through the book - "Clean code: A handbook of Agile Software Craftsmanship". Thought of jotting down some of the key points, just so that it helps myself to revive the tips often.

Meaningful names for variables

1. Use intention revealing names.
2. Avoid magic numbers (constants) and disinformation (misleading names).
3. Make meaning distinctions (do not use klass because class cannot be used).
4. Use pronounceable names, not short-cuts (dmy - date month year).
5. Use searching unique names. Do not use single letter variable names that is hard to search uniquely.
6. Don't use member prefixes like m_ or s_ as modern editors are good enough to differentiate them with coloring and formatings.
7. Class names should be nouns and Method names should be verbs.

 Functions:

1. Be small. Break it down as small as possible, may be 2 or 3 or 4 lines.
2. Should do just one thing and do it really well.
3. One level of abstraction per function.
4. The StepDown rule.
5. Number of arguments should not be more than 3. Zero arguments are the best. More arguments should ideally be extracted into a object with properties.
6. Avoid boolean arguments, as they are going to make the implementation bigger.
7. Prefer exceptions to return codes.
8. Error handing itself is one thing.
9. Don't repeat yourself.

Comments:

1. Don't comment bad code, rather rewrite it.
2. If you comment, accept that you failed to express yourself in the code.
3.  Why comments are bad - they become stale and old and finally lie about the code that is around.
4. Required or relevant comments are those - Legal comments, informative, explanation of intent, Warnings, clarifications, Amplifications, TODOs and Javadocs
5. Bad comments - mumbling, redundant, misleading, mandated, journel comments, noisy comments, last but not least - commented out code.

Formatting: