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:

 

Clear Case History Browser Blank Issue

This has been an intermittent issue in Windows 2003 Clear Case Source Control Version: 7.1.1.0.

Of late I have been using clear case and ended up into this issue. Figured out the solution through google search. So, thought of blogging it for my own reference later.

Original post is here: http://www-01.ibm.com/support/docview.wss?uid=swg21123280

Pasting the solution below which works for me always whenever I run into this issue:

Note: The following directions require you to edit the registry using the Windows Registry Editor. However, editing the Windows Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Use Registry Editor at your own risk. Before proceeding review the Microsoft KB article, KB256986 - Description of the Microsoft Windows Registry.

1. Open registry editor (Start > Run and type regedt32).
   
   
2. Navigate to the registry key HKEY_CURRENT_USER\Software\Atria\ClearCase\CurrentVersion
   
   
3. Delete the key Rational ClearCase History Browser
   
   
4. Close Registry editor.
   
   
5. Open History Browser and check the display.
   
   Note: When the above registry key is deleted clearhistory.exe rebuilds the registry key with its original defaults.