Software Testing - Best Practices And Principles To Write Unit Testing

According to this principle, mock out all the external Services and state and remember Unit test never uses

• Configuration settings.
• A database.
• Another Application/Service/file/network I/O or file system.
• Logging.

Principle 2. “Fail first and set a guard on the door"

Before you write piece of logic, first write your fail test. Afterwards, add or refactor your guard logics and throw proper exceptions or messages for the negative or an exceptional data. Finally, run it and pass the test.

Explanation of Unit Testing principles

Principle 1 - Suppose, you have a method 'IsValidUser' to verify the user name and password for the login.

Now, if you look at the line number 15 and 17, then you will see class 'UserLogIn' has a dependency to the class 'UserDataAccess' and it is tightly coupled. Now, the problem is you need to test a method 'IsValidUser' of a class class 'UserLogIn' and you have to avoid the dependency. If you call 'sValidUser', then it will call the method GetUserInfoByUseeName(userName) and according to Unit test principle, if we have a dependency to a method of another class, then we have to mock that object class. It means that we have to inject some dummy data to that object. In this example, we need to inject dummy data for the 'GetUserInfoByUseeName(userName). If we do so, then we will be able to verify the logics of the method ('IsValidUser()') in the 'UserLogIn' class.

In order to avoid the tight coupling code, we need to refactor the code. Later, I will explain what are dependency, tight coupling and loose coupling. Now, my main goal is to make you know Unit testing principle only. Let's refactor the class again.

Now, the class 'RefactoringUserLogIn' is loosely coupled and you can inject the implemented class of the 'IUserDataAccess' ,which will make your life easy to do Unit testing. Note that there are many ways to inject the implemented class. Later, I will show you that as well as how to mock an object of a class. During Unit testing, if you mock the 'IUserDataAccess', it means that you are implementing a dummy object of 'IUserDataAccess' and the method 'IsValidUser()' , it will be not able to get any data directly from the database or ORM via 'UserDataAccess' class.

Principle 2

More than 50 percent people fail their road driving test first time, then after practicing on the highway and seeking tips from others, they are ensuring their success in the road test. If you are already familiar with the Test-Driven-Development (TDD), then you are already familiar with the fail test. I will explain TDD at the end of this section.

Let me explain the guard logics in the method and how it will help you to pass your Unit testing. Let's say that we have a method ‘GetSumByPositiveNumber()’ and it has two parameters. The business requirements are always to pass the positive numbers and get the sum. Never pass the negative or zero values for the methods.

Now, according to your business requirement, if you pass the values of the parameters like 1 and 2, then the method will return 3, which is correct but what happens, if you pass the negative values as a parameter or some combination like (-5, -1), (-5, 1), (5, 0), (0, 0) etc.

If we put some guard logics into the method, then the test should be passed. We are throwing the exception for the negative data.

Best practices for writing Unit Testing

• If the old test fails for the extension of the method, which is introduced, then remove or enhance old test and avoid requirement conflict.
• If you remove a single line in your tested class and all the tests still pass, then you do not have enough unit tests.
• Developer will often run the test, so make the test easy to run.
• Test only public methods and public interface of the component
• Don't create instances of the classes directly inside a Unit test - use Factory Method.
• Refactor the unit test and keep it simple. Remember that the tests must be maintained by any code - so it's better to keep it simple.
• Any test should run in any order; so avoid dependencies between the tests.
• Test should be readable like a book; so write the comments in Asserts. Write the descriptive method names. Use Behavior-Driven-Development (BBD) technique.
• Test everything that can possibly break.
• Test everything, but not Private methods

Writing test scenario, test case and test data

Only Three Test Cases for Unit Testing, Nothing Else

1. Positive Test Cases - Correct data to check for the correct output.
2. Negative Test Cases - Broken or missing data to check for the proper handling.
3. Exception Test Cases - Giving an unexpected data or behavior and check for the exception caught properly or not.

Test data according to the test cases

Let’s set some test data and consider “GetSum()” as an example. Here, my main goal is to show you how can we set some test data for the test cases.

Type of test data

1. Positive Data
2. Negative Data
3. Exceptional Data

Positive data for positive test cases

The main goal of the positive test cases is to verify the functionality of the logics.

TestCase-1 - Given positive values should return the expected result

• TestData-1 - Set Input Parameters as firstNumber =1, secondNumber=1

Negative Data for Negative Test Cases

The main goal of the negative test cases is to get proper messages for the bad input according to your business requirements.

TestCase-2 - Given invalid values, you should produce invalid argument message.

• TestData-2 - Set the input parameters as firstNumber =-1, secondNumber =-1
• TestData-3 - Set the input parameters as firstNumber =-1, secondNumber = 1
• TestData-4 - Set the input parameters as firstNumber = 0, secondNumber = 1
• TestData-5 - Set the input parameters as firstNumber = 0, secondNumber =-1
• TestData-6 - Set the input parameters as firstNumber = 0, secondNumber = 0 etc.….

3.3.2.1.3 Exceptional data for exception test cases

The main goal of the exceptional test cases is to find out the proper exception handling with the proper messages, so that your code can’t break for the threshold limits.

Here, you can set the threshold limits of your test data. In .NET, the minimum value for a variable of type int is -2147483648 and the maximum value for a variable of type int is 2147483647.

TestCase3 - Given threshold limit values should throw an exception message.

• TestData-7 - Set the input parameters as firstNumber =1, secondNumber =2147483649
• TestData-8 - Set the input parameters as firstNumber =1, secondNumber = -2147483649
• TestData-9 - Set the input parameters as firstNumber =2147483649 secondNumber = -2147483649
• TestData-10 - Set the input parameters as firstNumber =2147483647, secondNumber=2147483647 etc.….

Naming convention of Test Method for Unit testing

Traditional principle of Unit Test

One Test Method is written to test one and only one method and one assert method should test only one expectation at a time.

In a short the principle says – “one function/method and one assert per test method”

So, let’s consider the bellow example

Comparing the Traditional Principle to the Real World

Test Scenario

Verify the “GetSum” Method

Test Cases

Positive Test Cases

TC1 - Given positive values, should return expected result

Test Data-1 - firstValue =5, secondValue =6

Negative Test Cases

TC2 - Given zero values, should produce invalid argument message

Test Data-2 - firstValue =0, secondValue =0

TC3 - Given negative values, should produce invalid argument message

Test Data-3 - firstValue =-5, secondValue =-6

Exceptional Test Cases

TC4 - Given threshold limit values, should throw exception message

Test Data-4 - firstValue =2147483647, secondValue =2147483647

Test Method Example

Now according to the traditional principle, let’s write the test method for the “GetSum”

Now according to the traditional principle we have covered the Positive Test Case with “Test Data-1”. But what about negative and exceptional test cases??

How do we cover the negative and exceptional test cases with traditional principle??

Behavior Driven Development (BDD)

Why Do We Need BDD

If we want to cover all of the behaviors of our test cases according to our previous example then we need to follow some technique so that we can write down all of the behaviors of the method. So, The BDD is the technique which gives us the opportunity to fulfillment for all of the test cases with standard and readable naming convention. Many peoples, many minds. There are many techniques to write the naming convention of the test method. But if really depends on you and your preference. There is nothing right or wrong if you follow some other technique. Anyway, in a short we can say that In BDD, components test their expected behavior.

Concept of BDD

1. Given I am a beginner to the BDD technique,I never used this technique before
2. When I read this tutorial for BDD,
3. then I have started liking it and I learn it.

BDD Naming convention

Test Scenario

Verify the “GetSum” Method

Test Cases

Positive Test Cases

TC1 - Given positive values, should return expected result

Test Data-1 - firstValue =5, secondValue =6

Test Method - Naming Convention,

GivenPositiveVaidValuesAsParams_WhenGetSumIsCalled_ThenItShouldReturnSumValue
Given_Positive_Vaid_Values_As_Params_When_GetSum_Is_Called_Then_It_Should_Return_Sum_Value

Negative Test Cases

TC2 - Given zero values, should produce invalid argument message

Test Data-2 - firstValue =0, secondValue =0

Test Method - Naming Convention,

GivenZeroValuesAsParams_WhenGetSumIsCalled_ThenItShouldThrowInvalidArgumentException
Given_Zero_Values_As_Params_When_GetSum_IsCalled_Then_It_Should_Throow_Invalid_Argument_Exception

TC3 - Given negative values, should produce invalid argument message

Test Data-3 - firstValue =-5, secondValue =-6

Test Method - Naming Convention,

GivenNegativeValues_WhenGetSumIsCalled_ThenItShouldThrowInvalidArgumentException
Given_Negative_Values_When_GetSum_Is_Called_Then_It_Should_Throw_Invalid_Argument_Exception

Exceptional Test Cases

TC4 - Given threshold limit values, should throw exception message

Test Data-4 - firstValue =2147483647, secondValue =2147483647

Test Method - Naming Convention

GivenMaxLimitValuesOfIntAsParams_WhenGetSumIsCalled_ThenItShouldThrowSumException
Given_Max_Limit_Values_Of_Int_As_Params_When_GetSum_IsCalled_Then_It_Should_Throw_Sum_Exception