Software Unit Testing and Best Practices

Software Unit Testing is about testing of individual units of source code. Those units are generally methods and they are grouped by class names (called as Test Case). 

For example, if you have an XYZUtility class which having methodA, methodB, methodC methods, you will potentially have an XYZUtilityTestCase class having methodATest, methodBTest and methodCTest tests.

Unit tests must cover as much code as they can while running, but it is not the primary purpose. Code coverage is prefferred to be high as a result but the main purpose of the unit tests are:

• Testing output of a function with specific inputs. Those inputs must include boundary (min/max) values and potential exceptional values (divide by 0 etc.). And the inputs are also preffered to be chosen for covering all condition cases of the method.
• Documenting the software. One of the self-documenting code development techniques is unit testing. It shows usage of the code section.
• Increasing modularity, flexibility and extensibility of the code along with concerning the developer with the interface before implementation, in Test Driven Development (TDD) approach.

There are also 5 important properties for unit tests that must be obeyed according to Andy Hunt's Pragmatic Unit Testing book.

• Automatic

Unit test results (pass/fail) must be controlled automatically with tools. And generally more than one tests are need to be run together. A test should not have a manual step which stops execution of all tests.

• Repeatable

A unit test must be repeatable. In other words, if it passes on a certain version of code, it must always pass with that code or if it fails on a certain version of code, it must always fail with that code. Database changes or other external services or files etc. should not change the result of the unit test.

• Independent

Unit test results must be independent of other unit tests. If a unit test result changes after changing the running order or other environment change (database data etc.), it can not be called as a unit test.

• Thorough

A unit test must control every condition as it can (all possibilities, exceptions, boundaries ...). Its code coverage must be as much as it can and controlled conditions are preferred to be logical and functional.

• Professional

Unit test code must obey coding standards of the project which it belongs to, because it also is  a professional code. Furthermore, it was stated before that unit test is another way of self-documenting code. Clean and understandable unit test code will bring better documentation.

As a last word, for providing repeatable and independent unit tests, using mock objects is a good practice. Mock objects replaces the external sources (database, services, etc.) and returns predefined results. A good object oriented design having required amount of interfaces will  simplfy the creation of mock objects. You can also use some API's like EasyMock or Mockito. 

10 Software Documentation Best Practices

1. Perform documentation as required (e.g. %10 of total production time). No documentation is never a good solution as much as excessive documentation. It may include code documentation, requirement specifications, design documents, test documents, user manuals etc. Those documents are needed to be managed and shared also, by using version controlling tools and/or web based platforms.
2. Code documentation is important. Best way of doing this is producing self-documenting code. Variable, method, class, package etc. names must be meaningful and codeflow must be pure. For very complex code sections, short comment lines may be included. Javadoc-like standard entries are not required but may be added for auto document generation from code.
3. For the future developers, short and useful design documents may be prepared including key design features and UML diagrams. Practical user help documents may be useful also. These documents must not include unnecessary bulk info.
4. Requirements/issues/backlog item/function points tracking is important. For that operation, a tracking tool is more effective (it will have quick search, edit capabilities and a few more features) than writing them into a plain text file.
5. Test tracking is also important. Test scenarios and results may be tracked using tools (or with text files, which is not preferred) and associated with related requirements. By doing this, functional status of software may be monitored easily.
6. Documentation is a live process. If you produce some documents, it is a good practice to update or produce new version of those documents until the end of development process. If a document is not up-to-date, it is practically worthless.
7. For text file documents, versioning is important. For each new version of a document, a new version number (which is given with a stable versioning strategy) must be given. Also a version tracking table having change info may be included for better tracking.
8. Having a consistent document template is important for companies. Header, footer, headings, font sizes must be consistent in document and among other documents for better readability. It is also a good practice that having a cover page, table of content, table of pictures and a glossary for documents.
9. Document formatting, language usage and typing are other physical issues about documents and attention must be paid. Typing errors, unconsistent table sizes, indentations etc. will distract the reader.
10. Saving "lessons-learned" info on a shared place is another good practice. Those items are some useful experiences (information or code/configuration sections etc.) about development process which may not be included in standard process documents. Lessons-learned info may give acceleration to the current developers or future developers about some challenging and repeating operations.