Testing Our Code (As a Developer I Should)

Rules

Success baseline Start by defining a unit test that represents a common, successful path through your code. This test should represent the most likely scenario for executing your code.

Parameter mix Create a unit test that provides a varied mixture of parameters for a given method. This will ensure that more than just the success path works effectively. Consider creating this scenario as a data-driven unit test.

Bounds checking Create one or more unit tests that test the upper and lower limits of your code. That is, if your method takes a numeric value, you will want to test that method with values that represent both the upper and lower range of the data type.

Null values Make sure your unit tests measure what happens when null values are passed to a given method or property.

Error conditions Create unit tests that trigger error conditions in your code. You can tell the unit test that you expect a certain error as a result. If that error is not thrown, then the test will fail.

Code coverage scenarios Make sure that all the code in your method is called by one or more unit tests. You do not want untested code sitting inside of conditional statements. If this happens, write tests that hit those conditions inside your application code.

 

 

Best Practices

• Write one test for each scenario you should test each outcome or scenario independently. If your method has a number of expected outcomes, write a test for each scenario.
  
• Create atomic unit tests your unit tests should not require others tests (or a sequence of tests) to be run prior to their execution or as part of their execution.
  
• Cover all conditions your unit tests should cover all cases. An effective set of unit tests covers every possible condition for a given method, including bounds checks, null values, exceptions, and conditional logic.
  
• Run without configuration your unit tests should be easy to run (and rerun). They should not require setup or configuration. You do not want to define tests that require a specific environment every time you run your tests (or they will not be run). If setup is required, code that into a test-initialize script.
  
• Test a common application state your unit tests should be run against a common, standard, good state. For example, if your application works with data, this data should be set to common state prior to the execution of each unit test. This ensures that one test is not causing an error in another test.

Source:- 70-547 training kit book