What is Unit Testing

MInd map

You should make a mind map
- What you know about it
- How it is different from other types of tests
  - What kind of tests do you know
You have about 5 minutes to think and make it

What?

Unit testing is a very wide topic
- It can get really complicated
- But don't be afraid to dive into it
  - Basic concepts are what you would learn during this course
  - This will help you to build a strong foundation
    - And be confident in yourself

Definition

A unit test is a piece of code written by a developer that exercises a very small, specific area of functionality of the code being tested.

"Program testing can be used to show the presence of bugs, but never to show their absence!"
Edsger Dijkstra, [1972]

Definition

“A unit test is a piece of code that invokes a unit of work and checks one specific end result of that unit of work. If the assumptions on the end result turn out to be wrong, the unit test has failed. A unit test’s scope can span as little as a method or as much as multiple classes.”

“A unit of work is the sum of actions that take place between the invocation of a public method in the system and a single noticeable end result by a test of that system. …”

The Art of Unit Testing, Second Edition

Unit testing "examples"

Lifecycle

Software Development Lifecycle

Lifecycle

QUESTION:
Who’s responsible for the quality of a software system?

ANSWERS:

- QA Engineer

- Software Engineer

- Everyone

- No one

Right answer – everybody in the team, not just QAs. Developers are responsible for the code to run correctly always BEFORE committing.

Live demo

What unit testing is not?

Unit Testing is NOT Test Driven Development (TDD)

and

Test Driven Development is NOT only Unit Testing

TDD, Test-first development and Test-driven-design are different concepts that rely on Unit Testing.

But they are not the same and should not be confused! We will not cover TDD here.

TDD is a very advanced practice and skill

Even if looks relatively simple process to you

Why not to do it?

Reasons not to write unit tests

"Writing tests is too hard."

"Testing is not my job."

"My code is too simple for tests."

"I don't have enough time to write tests."

"I don't know how to write tests."

Most companies that have lengthy software development lifecycle adopt some version of unit testing process.

Testing Pyramid

Benefits

For readability / more than just documentation – shows the intended practical usage of the method/class
To reduce cost of change and maintenance
To find bugs easier - does your code work correctly
To improve Code Design
But it should be done the right way – we’ll later give you an idea about it and we’ll learn more and more about unit testing throughout the whole rest of the course, not just in today’s session

Diagrams

Unit Testing Overview

Manual Testing

You have already done unit testing
- Manually, by hand
Manual tests are less efficient
- Not structured
- Not repeatable
- Not on all your code
- Not easy to do as it should be

Unit Testing - Example

int Sum(int[] array)
{
    int sum = 0;
    for (int i = 0; i < array.Length; i++)
        sum += array[i];
    return sum;
}

void Sum_Should()
{
 if (Sum(new int[]{ 1, 2 }) != 3)
    throw new TestFailedException("1 + 2 != 3");
 if (Sum(new int[]{ -2 }) != -2)
    throw new TestFailedException("-2 != -2");
 if (Sum(new int[]{ }) != 0)
    throw new TestFailedException("0 != 0");
}

Unit Testing

Tests are specific pieces of code
In most cases unit tests are written by developers, not by QA engineers
Unit tests are released into the code repository
- (TFS / SVN / Git) along with the code they test
Unit testing framework is needed
- Visual Studio Team Test (VSTT)
- NUnit, MbUnit, Gallio, etc.

Unit Testing

All classes should be tested
All methods should be tested
- Trivial code may be omitted
  - E.g. property getters and setters
- Private methods can be omitted
  - Some gurus recommend to never test private methods → this can be debatable
Ideally, all unit tests should pass before check-in into the source control repository

Unit Testing - Why bother do it?

Dramatically decreased number of defects in the code*
Improved code design
- Helps introduce SRP
- Helps introduce loose coupling
Good documentation
- Code result expectations
- Self-documenting code
Reduced cost of change
- Easier, more efficient refactoring

Unit Testing - What makes one good?

A good unit test should:
- runs quickly
- be automated and repeatable
- be easy to implement
- be relevant tomorrow
- be consistent in its results
- have full control of the unit under test
- be fully isolated

Unit Testing - What makes one good?

When it fails, it should be easy to detect what was expected and determine how to pinpoint the problem.
Anyone should be able to run it with the push of a button.

Unit Testing Basics

(examples are with MSTest syntax)

Attributes

Test code is annotated using custom attributes:
- [TestClass] - denotes a class holding unit tests
- [TestMethod] - denotes a unit test method
- [ExpectedException] - test causes an exception
- [Timeout] - sets a timeout for test execution
- [Ignore] - temporary ignored test case
- [ClassInitialize], [ClassCleanup] - setup / cleanup logic for the testing class
- [TestInitialize], [TestCleanup] - setup / cleanup logic for each test case

Assertions

Predicate is a true / false statement
Assertion is a predicate placed in a program code (check for some condition)
- Developers expect the predicate is always true at that place
- If an assertion fails, the method call does not return and an error is reported
- Example of assertion:

Assert.AreEqual(expectedValue, actualValue, "Error message.");

Assertions examples

Assertions check a condition
- Throw exception if the condition is not satisfied
Comparing values for equality

Assert.AreEqual(expected_value, actual_value [,message])

Comparing objects (by reference)

Assert.AreSame(expected_object, actual_object [,message])

Assertions examples

Checking conditions

Assert.IsTrue(condition)
Assert.IsFalse(condition)

Forced test failure

Assert.Fail(message)

Checking for null value

Assert.IsNull(object [,message])
Assert.IsNotNull(object [,message])

And many more

Code Coverage

Code coverage
- Shows what percent of the code we’ve covered
- High code coverage means less untested code
- We may have pointless unit tests that are calculated in the code coverage
70-80% coverage is a good start
You should try to reach over 90%

Example

public class Account
{
  private decimal balance;

  public void Deposit(decimal amount)
  {
    this.balance += amount;
  }

  public void Withdraw(decimal amount)
  {
    this.balance -= amount;
  }

  public void TransferFunds_Should_Condition(
    Account destination, decimal amount) { … }

  public decimal Balance { … }
}

The 3A Pattern

Arrange all necessary preconditions and inputs
Act on the object or method under test
Assert that the expected results have occurred

[TestMethod]
public void TestDeposit() // TODO: Improve test name
{
  // Arrange
  BankAccount account = new BankAccount();

  // Act
  account.Deposit(125.0);

  // Assert
  Assert.AreEqual(125.0, account.Balance, "Balance is wrong.");
}

Isolation

In order to make a true unit test you must run it in isolated environment
- Ex: If you want to test if the fuel pump of an engine works, you don't need the engine itself, neither the car
- You should make a fake object of the engine and the car and run the test in order to verify that the fuel pump works
There are techniques we will discuss later
- You can do it manually
- Or with a framework

Naming Conventions

MethodName_StateUnderTest_ExpectedBehavior
- IsAdult_AgeLessThan18_False
MethodName_ExpectedBehavior_StateUnderTest
- IsAdult_False_AgeLessThan18
Should_ExpectedBehavior_When_StateUnderTest
- Should_ThrowException_When_AgeLessThan18
When_StateUnderTest_Expect_ExpectedBehavior
- When_AgeLessThan18_Expect_isAdultAsFalse

Testing Frameworks

MSTest

MSTest is very well integrated with Visual Studio
- Create test projects and unit tests
- Execute unit tests
- View execution results
- View code coverage
Located in the assembly
Microsoft.VisualStudio. QualityTools.UnitTestFramework.dll
Had some limitations in the past but it is very well structured and the new version is fully featured

MSTest - Example

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class AccountShould
{
  [TestMethod]
  public void TransferFunds_ShouldUpdateBothAccountBalances_WhenInvoked()
  {
    // Arrange
    Account source = new Account(200.00M);
    Account dest = new Account(150.00M);

    // Act
    source.TransferFunds(dest, 100.00M);

    // Assert
    Assert.AreEqual(100.00M, source.Balance);
    Assert.AreEqual(250.00M, dest.Balance);
  }
}

NUnit

Test code is annotated using custom attributes
Test code contains assertions
Tests organized as multiple assemblies
NUnit provides:
- Creating and running tests as NUnit Test Projects
- Visual Studio support

NUnit

Two standalone execution interfaces
- GUI - nunit-gui.exe
- Console - nunit-console.exe
Integrates with Visual Studio with test adapter (Nuget packages)

NUnit - Example

using NUnit.Framework;

[TestFixture]
public class AccountTest
{
  [Test]
  public void TransferFunds_ShouldUpdateBothAccountBalances_WhenInvoked()
  {
    // Arrange
    Account source = new Account(200.00M);
    Account dest = new Account(150.00M);

    // Act
    source.TransferFunds(dest, 100.00M);

    // Assert
    Assert.AreEqual(100.00M, source.Balance);
    Assert.AreEqual(250.00M, dest.Balance);
  }
}

Audience Choice

Choose a naming convention

MethodName_StateUnderTest_ExpectedBehavior
MethodName_ExpectedBehavior_StateUnderTest
Should_ExpectedBehavior_When_StateUnderTest
When_StateUnderTest_Expect_ExpectedBehavior

Do we really need to choose only one?

Answer: YES. Conventions are hard to adopt but once achieved it brings us a lot of benefits.

Choose a testing framework

MSTest
- or
NUnit
Later we will choose isolation framework too

Best Practices

Volunteer?

We need a volunteer to write a simple unit test

public string ReverseString(string text)
{
    StringBuilder sBuilder = new StringBuilder();
    for (int i = text.Length - 1; i >= 0; i--)
    {
        sBuilder.Append(text[i]);
    }

    return sBuilder.ToString();
}

What case we do not cover here

When should a test be removed or changed?

Generally, a passing test should never be removed
- These tests make sure that code changes don't break working code
A passing test should only be changed to make it more readable
When failing tests don't pass, it usually means there are conflicting requirements

[Test]
void Sum_ShouldThrow_WhenFirstPassedNumberIsNegative()
{
  Assert.ShouldThrow(() => Sum(-1, 1, 2));
}

When should a test be removed or changed?

New features allow negative numbers
New developer writes the following test:
Earlier test fails due to a requirement change
Two course of actions:
- Delete the failing test after verifying it is invalid
- Change the old test:
  - Either testing the new requirement
  - Or test the older requirement under new settings

Test should reflect reality

Consider the following method:

int Sum(int a, int b) -> return sum of a and b

What’s wrong with the following test?

public void Sum_AddsOneAndTwo()
{
    int result = Sum(1, 2);
    Assert.AreEqual(4, result, "Bad sum");
}

A failing test should prove that there is something wrong with the production code, not with the unit test code

Assert messages

Assert message in a test could be one of the most important things
- Tells us what we expected to happen but didn’t, and what happened instead
- Good assert message helps us track bugs and understand unit tests more easily
Example:
- "Withdrawal failed: accounts are not supposed to have negative balance."

Assert messages

Express what should have happened and what did not happen
- "Verify() did not throw any exception"
- "Connect() did not open the connection before returning it"
Do not:
- Provide empty or meaningless messages
- Provide messages that repeat the name of the test case

Assert messages

Avoid multiple asserts in a single test case*
- If the first assert fails, the test execution stops for this test case
- Affect future coders to add assertions to test rather than introducing a new one

void Sum_Test()
{
    Assert.AreEqual(3, Sum(1001, 1, 2));
    Assert.AreEqual(3, Sum(1, 1001, 2));
    Assert.AreEqual(3, Sum(1, 2, 1001));
}

Additional Resources

Resources

Read it, Watch it, Test it

Unit Testing Telerik Academy Alpha

UT

Table of contents

What is Unit Testing

MInd map

What?

Definition

Definition

Unit testing "examples"

Lifecycle

Lifecycle

Live demo

What unit testing is not?

Why not to do it?

Testing Pyramid

Benefits

Diagrams

Unit Testing Overview

Manual Testing

Unit Testing - Example

Unit Testing

Unit Testing

Unit Testing - Why bother do it?

Unit Testing - What makes one good?

Unit Testing - What makes one good?

Unit Testing Basics

Attributes

Assertions

Assertions examples

Assertions examples

Code Coverage

Example

The 3A Pattern

Isolation

Naming Conventions

Testing Frameworks

MSTest

MSTest

MSTest - Example

NUnit

NUnit

NUnit

NUnit - Example

Audience Choice

Choose a naming convention

Choose a testing framework

Best Practices

Volunteer?

When should a test be removed or changed?

When should a test be removed or changed?

Test should reflect reality

Assert messages

Assert messages

Assert messages

Additional Resources

Resources

Questions?

Unit Testing
Telerik Academy Alpha