Developer Checklist For Unit Test

 Related Articles:

• Inside Out: TDD using C#
• Visual Studio and .NET Unit Test Framework
• Unit Test Automation with Visual Studio

Introduction

Unit Tests play an important role in delivering high quality software solutions. An ideal unit test is a piece of code (automated test) written by a developer which exercises a small but specific area of code functionality to ensure that it works as expected.

Why Unit Test

According to the Test Triangle, in a software project the largest number of tests must be Unit Tests. Because multiple individual Unit Tests exercises small units of functionality which spans over various areas of functionality offered by the software solution.



Unit Test Check-List

While writing Unit Test(s) following points must be considered and followed by the Developers and SDETs.

Check	Description	Mart
Self-Describing Names	Unit Test method names must be Self-Describing and Pascal case. For example choose Add_New_Customer_With_Valid_AcccountNumber over AddCustomer_with_validAcc or addCustomer etc. Also focus on naming style, keep the naming style consistent across all the tests methods and test.
A3 (Arrange, Asset, Act)	Make sure that all the Test Methods are designed around Arrange, Act and Assert. If required Refactor your code to fall into these three sections.
Test Happy and Sad Path	The unit test should cover all possible scenarios and strive for high code coverage and ensuring good quality metrics. Unit Test methods must exercise all possible use case scenarios to test the input validations, interactions, errors messages, edge cases and exceptions etc.
Make use of Attributes	Use Test Framework provided Attributes like:
	[TestCategory("<describe if its Unit or Integration Test>")] [TestCategory("<Which section of the application is being tested>")] [Priority(n), TestCategory("<define if it’s Gated or not-Gated build Tests>")] [WorkItem(xxxx)] [Owner("<who wrote this test>")]
Have least number of asserts per test (if applicable)	A good Unit test should only have limited # of assert statements. It should unit test the very functionality, as indicated in its descriptive name. A well-defined Unit Test should contain only one assert statement per test and must not try to exercise all the validation/boundary checks etc. by multiple Assert() in one Unit Test method.
Keep assert messages descriptive	Keep assert messages descriptive Use descriptive messages to improve readability of code and the build log. Assert.IsTrue(customer.IsExist,"The Customer is not found in the Database");
Unit != Integration	There is a very fine line between Unit and Integration, if you happen to go beyond what your function is supposed to be doing then you are not writing a Unit Test. I.e. Unit Test doesn’t focus on interaction with external systems and software layers/dependencies. Test Doubles (for example Microsoft Fakes framework) comes into the picture to write unit tests which has dependencies on external libraries and systems etc.
Follow OOP Design and Adopt DI	Following Dependency Injection will allow to convert potential Integration Tests into small and quickly testable Unit Tests by taking advantages of Test Doubles (e.g. Microsoft Fakes, Moq, FakeItEasy frameworks etc.)
Should be thorough	Unit Tests are supposed to test all the possible areas of functionality that are subject to failure due to incorrect input/validation checks/boundary checks etc. for given function/method.
Must be Repeatable	Unit Tests must be repeatable for every build and must produce the same results. The development best practice suggests that if you are working on code that is impacting a Unit Test then you must fix the affected Unit Test as well and ensure that it passes.
Have to be Independent	Unit Tests must be independent of another test. In other words, no collateral damage. Hence, a Unit Test must focus only on a small aspect of big functionality. When this Unit Test fails, it should be easy to discover where the issue is in the code. I.e. can be tested in isolation.
Keep it Professional	Even though at times Unit Tests may appear to be very simple and small, you must write Unit Tests with coding practices as good as you use for your main development coding. You may want to follow Refactoring, Code Analysis and Code Review practices and so on as for your Test Projects as well.
No Collateral Damage	Make sure to Run all related Unit Tests after any dev code change big or small; to verify and ensure that no collateral damage occurs or has been introduced.
If you break it, You bought it	If you are working on a feature and to verify no collateral damage, as a best practice run all the Unit Tests. If you observe that some Unit Tests started failing because of your code changes then you own to fix those broken Unit Tests to make sure that continue to pass.
Track and maintain the tests	The test code changes should be tracked and maintained as on-going effort. Continue to follow the design principles and coding guidelines.
Code Review the Tests	Just like any other Dev code, Unit Tests also needs to be code reviewed by peer. Regardless of size of the test; follow the process.
	Code review might include reviewing the name of test method, scenarios covered, conditions checked, scope of assertions and code / design smells, etc.