Watch YouTube Video Here...

Software testing

Software testing is the art of measuring and maintaining software quality to ensure that the user expectations and requirements, business values, non-functional requirements (such as security, reliability, and recoverability), and operational policies are all met. Testing is a team effort to accomplish the well-understood and agreed-upon minimum quality bar and definition of “done”.
Definition of Done (DOD): is a team definition and commitment to quality to be applied to the solution during each iteration (this may also occur at the Task or User Story level, too). Consider the design, code reviews, refactoring, and testing when discussing and defining your definition of done.
Understanding and Adapting TDD
TDD is a happening term in the industry these days, especially among those software development organizations that are practicing the Agile development methodology.
TDD is an evolutionary approach and mindset towards software development that enforces writing Unit Tests as you are coding the functionality or feature.
TDD gives an opportunity to think as a “user of the code” instead of an “implementer of the code”. Eventually, TDD helps in better design, quality and test coverage.
What is the Unit Test
An ideal unit test is a piece of code written by a developer that exercises a small but specific area of code functionality to ensure that it works as expected and can be tested in isolation from other units.
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 contribute to Integration Testing and so on.
The image below also depicts that, over the period of time of a project, a Unit Test needs to be continuously written and run for software quality.
Benefits of TDD
Unit testing helps in various ways as in the following:
  1. Reduce bugs by identifying all the use case scenarios to reflect intent (end user's mindset, business needs, expected functionality, and business validations, and so on).
  2. Less-and-less time on debugging.
  3. Avoid collateral damage, in other words, a fix in one area may break functionality in another possibly related/unrelated area.
  4. Helps you achieve YAGNI that is "You Aren't Gonna Need It". In other words, saves you from writing code functionality that you don't need.
But I am a Developer, Not a Tester
First, creating a Unit Test is the developer's responsibility. Agreed, developers are not testers and that is true of testers too. But thinking of the most common scenarios worth testing that might cause failure to your code functionality is all that you need to code in your Unit Tests.
Got it, but I don't have a Testing Mind Set
Not having a Testing Mind Set is actually a genuine issue and this happens because developers usually never think of testing their code until it's deployed to QA or production. To overcome this issue you must pair with a QA Engineer or Software Development Engineer in Test (SDET) in your team. You must write all the possible test areas that you think of and get it reviewed.
Career Tip: In today's software world, a unit testing skill is a major requirement for any developer, lead, or architect position.
Requirements for other types of testing as well
Do I need to do other types of testing as well? From a developer's point of view, the short and straight answer is no, but many teams and organizations require their developers to write even Integration, Load, and Stress Tests as well. A dedicated QA/Test team is usually responsible for doing a non-unit type of testing, whether it is manual or automated.
Career Tip: Educate yourself about other types of testing.
System Under Test (SUT)
System Under Test (SUT) is the system that will be tested by Unit Tests for code accuracy and possible scenarios that might either break the functionality at runtime or not produce legitimate results.
Assume you are working on a Bank Application's Business Logic (BankApplication.dll) and your code looks as in this:
  1. namespace BankApplication.Savings
  2. {
  3. public class Account
  4. {
  5. private double accountBalance = 0.00;
  6. private bool accountStatus = false;
  8. private enum Roles
  9. {
  10. Customer,
  11. Manager
  12. }
  13. public bool IsAccountActive(string accNumber)
  14. {
  15. return accountStatus;
  16. }
  18. public double Balance(string accNumber)
  19. {
  20. return accountBalance;
  21. }
  23. public double Deposit(string accNumber, double amount)
  24. {
  25. return accountBalance = accountBalance + amount;
  26. }
  28. public double Withdwral(string accNumber, double amount)
  29. {
  30. return accountBalance = accountBalance - amount;
  31. }
  33. private bool ActivateAccount(string accNumber, Roles userRole)
  34. {
  35. accountStatus = true;
  36. return accountStatus;
  37. }
  38. }
  39. }
This Bank Application's DLL should work properly, assuming all the right data and parameters are provided. But when you start thinking from a Test Driven Development (TDD) perspective and you put the DLL under test then you start detecting the areas of further improvement and refactoring.
What to Unit Test
But what do I unit test? the most critical and common area of Unit Testing can be categorized under Boundary and Error Conditions.
Boundary Conditions
Boundary conditions are very critical to the success of any software code ever written. All your business validation/rules are actually a candidate for Boundary Unit Tests.
Identifying boundary conditions is very important for unit testing, such as:
  1. Empty or missing values (such as 0, "", or null).
  2. Inappropriate values that are not realistic from a business point of view, such as a person's age of -1 or 200 years or so.
  3. DOB is tomorrow's date or time in the future.
  4. Duplicates in lists that shouldn't have duplicates.
  5. The password is the same as either First name or Last name
  6. Special characters or case related conditions.
  7. Formatting of data, for example, the name must be capitalized. For example Vidya Vrat, Agarwal.
  8. Type of acceptable values in a field. For example, the name can't hold a numeric, and age can't hold letters.
  9. Range is another critical thing to test and it's often coded as business validation rules.
Error Conditions
Building a real-world application causes real-world errors at run-time and errors do happen. Hence, you should be able to test that your code handles all such errors, for example, think of the following scenarios:
  1. Can't handle DivideByZeroException
  2. Consider the scenario of AccessDenied
  3. Don't ignore NullReferenceExceptions
  4. Check for existence; FileNotFoundException, DirectoryNotFoundException and so on
Properties of a Good Unit Test
Units Tests are very simple and usually small C# code segments, but there are a few criteria that can really define what a good Unit Test is. Here are the properties that a good Unit Test must have:
Automatic: Each Test must “Automatically” exercise small functionality in terms of invoking the test and verifying the results.
Thorough: Unit Tests are supposed to test all the possible areas of functionality that are subject to failure due to incorrect input.
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.
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.
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.
Structure of a Unit Test - Arrange, Act and Assert
An ideal unit test code is divided into the following three main sections:
  1. Arrange: Set up all conditions needed for testing (create any required objects, allocate any needed resources, and so on).
  2. Invoke the method to be tested with possible parameters or values.
  3. Assert: Verify that the tested method returns the output as expected.
Let's follow TDD
From the SUT we have, let's focus on a piece of production code.
  1. private bool accountStatus = false;
  3. public bool IsAccountActive(string accNumber)
  4. {
  5. return accountStatus;
  6. }
The IsAccountActive() function is supposed to return the account status of a provided account #. We will be writing tests to verify the behavior and then fixing the production code to make the Tests Pass and repeat the same with more scenarios and possibilities (use case, business rules/validations, and so on.)
Scenario #1: To test this production code we add [TestMethod] TestAccountStatus_Active_Success() to our TDD Suite (Unit Test Project).
  1. [TestMethod]
  2. public void TestAccountStatus_Active_Success()
  3. {
  4. Assert.IsTrue(obj.IsAccountActive("1234"),"Failed Account is not Active");
  5. }
The test failed, because we have not yet implemented the production code.
Let's implement the IsAccountActive() in the code to make the test pass. New code additions are:
  1. public bool IsAccountActive(string accNumber)
  2. {
  3. if (accNumber != null)
  4. {
  5. accountStatus = true;
  6. }
  7. else
  8. {
  9. accountStatus = false;
  10. }
  12. return accountStatus;
  13. }
Repeat it with more validation and business rules
What would be the response from the caller of the API if null is passed as an account number? Let's say the API must throw an ArgumentException.
Scenario #2: To verify this behavior add a Test First and we will use the Microsoft Test provided attribute [ExpectedException(typeof(ArgumentException))] to verify the exception the caller will be expecting in a real situation.
  1. // Exception is thrown if Null is passed as account number
  2. [TestMethod][Priority(0)]
  3. [ExpectedException(typeof(ArgumentException))]
  4. public void TestAccountStatus_ArgumentException_Success()
  5. {
  6. obj.IsAccountActive(null);
  7. }
Since our production or development code is not yet ready to handle this scenario, this test is supposed to fail and the reason is shown on the right-side panel (I underlined in Green).
Refactor-Test and Test Further More
Let's refactor our production or development code to make the TestAccountStatus_ArgumentException_Success() test case pass. The new code additions are highlighted in Green.
  1. public bool IsAccountActive(string accNumber)
  2. {
  3. if (accNumber != null)
  4. {
  5. accountStatus = true;
  6. }
  7. else
  8. if (accNumber == null)
  9. {
  10. throw new ArgumentException("Account number Can't be Null");
  11. }
  12. else
  13. {
  14. accountStatus = false;
  15. }
  17. return accountStatus;
  18. }
Now let's re-run the test TestAccountStatus_ArgumentException_Success() and observe the results.
Scenario #3: Now let's verify the behavior if we pass White Space " " as an account number and expect an ArgumentException is thrown. We will use the [ExpectedException(typeof(ArgumentException))] attribute.
  1. [TestMethod] [Priority(0)]
  2. [ExpectedException(typeof(ArgumentException))]
  3. public void TestAccountStatus_AccountNumberWhiteSpace_ArgumentException_Success()
  4. {
  5. obj.IsAccountActive(" ");
  6. }
Run the test and you will see the result as shown in the image below:
Let's refactor the code and it will look as shown below. The new code additions are:
  1. public bool IsAccountActive(string accNumber)
  2. {
  3. if (accNumber != null)
  4. {
  5. accountStatus = true;
  6. }
  7. else
  8. if (String.IsNullOrWhiteSpace(accNumber))
  9. {
  10. throw new ArgumentException("Account number Can't be Null or have
  11. White Spaces");
  12. }
  13. else
  14. {
  15. accountStatus = false;
  16. }
  18. return accountStatus;
  19. }
Let's re-run the test and observe the results:
The test still fails, though we added the right condition to verify WhiteSpace.
Let's Debug the Test
Add a breakpoint to the failing test at the line where you are invoking the production code as in the following:
Right-click in the code editor and select Debug Tests as shown in the image below.
This will start Test Execution in Debug mode and you will see a screen as shown below:
Press F11 and you will be taken to the Production code to debug it further.
Press F10 to Step-Over and keep pressing F10 until the Debug session ends and you will observe the flow as shown below:
So what we discovered is that the first condition accNumber!= null is true even if WhiteSpace has been passed as the account number. Hence, it's another opportunity to refactor the production code and re-run the Test(s). The new code additions are:
  1. public bool IsAccountActive(string accNumber)
  2. {
  3. if (String.IsNullOrWhiteSpace(accNumber))
  4. {
  5. throw new ArgumentException("Account number Can't be Null or have
  6. White Spaces");
  7. }
  8. else
  9. {
  10. accountStatus = true;
  11. }
  13. return accountStatus;
  14. }
Test Often
After each Test addition or refactoring session, re-run the tests in the Test Explorer to ensure that previously passing tests haven't begun failing, in other words, there is no Collateral Damage.
YouTube Video
https://www.youtube.com/watch?v=pzonnSyqVfc