Updated coding standard to explain unit testing

Moved the sharing map test into the appropriate folder

Author: thk123

CODING_STANDARD

@@ -26,23 +26,23 @@ Whitespaces:
 - No whitespaces in blank lines
 - Put argument lists on next line (and ident 2 spaces) if too long
 - Put parameters on separate lines (and ident 2 spaces) if too long
-- No whitespaces around colon for inheritance, 
+- No whitespaces around colon for inheritance,
   put inherited into separate lines in case of multiple inheritance
 - The initializer list follows the constructor without a whitespace
   around the colon. Break line after the colon if required and indent members.
 - if(...), else, for(...), do, and while(...) are always in a separate line
-- Break expressions in if, for, while if necessary and align them 
+- Break expressions in if, for, while if necessary and align them
   with the first character following the opening parenthesis
 - Use {} instead of ; for the empty statement
-- Single line blocks without { } are allowed, 
+- Single line blocks without { } are allowed,
   but put braces around multi-line blocks
-- Use blank lines to visually separate logically cohesive code blocks 
+- Use blank lines to visually separate logically cohesive code blocks
   within a function
 - Have a newline at the end of a file
 
 Comments:
 - Do not use /* */ except for file and function comment blocks
-- Each source and header file must start with a comment block 
+- Each source and header file must start with a comment block
   stating the Module name and Author [will be changed when we roll out doxygen]
 - Each function in the source file (not the header) is preceded
   by a function comment header consisting of a comment block stating
@@ -75,9 +75,9 @@ Comments:
 - Use #ifdef DEBUG to guard debug code
 
 Naming:
-- Identifiers may use the characters [a-z0-9_] and should start with a 
+- Identifiers may use the characters [a-z0-9_] and should start with a
   lower-case letter (parameters in constructors may start with _).
-- Use american spelling for identifiers. 
+- Use american spelling for identifiers.
 - Separate basic words by _
 - Avoid abbreviations (e.g. prefer symbol_table to of st).
 - User defined type identifiers have to be terminated by 't'. Moreover,
@@ -136,7 +136,7 @@ C++ features:
 - Avoid iterators, use ranged for instead
 - Avoid allocation with new/delete, use unique_ptr
 - Avoid pointers, use references
-- Avoid char *, use std::string 
+- Avoid char *, use std::string
 - For numbers, use int, unsigned, long, unsigned long, double
 - Use mp_integer, not BigInt
 - Use the functions in util for conversions between numbers and strings
@@ -146,13 +146,13 @@ C++ features:
 - Use instances of std::size_t for comparison with return values of .size() of
   STL containers and algorithms, and use them as indices to arrays or vectors.
 - Do not use default values in public functions
-- Use assertions to detect programming errors, e.g. whenever you make 
+- Use assertions to detect programming errors, e.g. whenever you make
   assumptions on how your code is used
-- Use exceptions only when the execution of the program has to abort 
+- Use exceptions only when the execution of the program has to abort
   because of erroneous user input
-- We allow to use 3rd-party libraries directly. 
-  No wrapper matching the coding rules is required. 
-  Allowed libraries are: STL. 
+- We allow to use 3rd-party libraries directly.
+  No wrapper matching the coding rules is required.
+  Allowed libraries are: STL.
 - When throwing, omit the brackets, i.e. `throw "error"`.
 - Error messages should start with a lower case letter.
 - Use the auto keyword if and only if one of the following
@@ -165,12 +165,30 @@ Architecture-specific code:
 - Don't include architecture-specific header files without #ifdef ...
 
 Output:
-- Do not output to cout or cerr directly (except in temporary debug code, 
+- Do not output to cout or cerr directly (except in temporary debug code,
   and then guard #include <iostream> by #ifdef DEBUG)
 - Derive from messaget if the class produces output and use the streams provided
   (status(), error(), debug(), etc)
 - Use '\n' instead of std::endl
 
+Unit tests:
+ - Unit tests are written using Catch: https://github.com/philsquared/Catch/
+ - For large classes:
+    - Create a separate file that contains the tests for each method of each
+      class
+    - The file should be named according to
+      `unit/class/path/class_name/function_name.cpp`
+ - For small classes:
+    - Create a separate file that contains the tests for all methods of each
+      class
+    - The file should be named according to unit/class/path/class_name.cpp
+ - Catch supports tagging, tests should be tagged with all the following tags:
+    - [core] should be used for all tests unless the test takes more than 1
+      second to run, then it should be tagged with [long]
+    - [folder_name] of the file being tested
+    - [class_name] of the class being tested
+    - [function_name] of the function being tested
+
 You are allowed to break rules if you have a good reason to do so.
 
 Pre-commit hook to run cpplint locally