Unit testing for dummies

Use the same naming method for test classes.

Choose a “talking” method for naming methods of testing classes

сlass CalculatorTests
{
        public void Sum_2Plus5_7Returned()
        {
 	    // …
        }
}

Choose a test framework that suits you

What to test and what not?

1. Simple code without dependencies. Most likely here everything is clear. You can not test it.
2. Complex code with lots of dependencies. Hmm, if you have this code, it smells of God Object and strong connectivity. Most likely, refactoring will be nice. We will not cover this code with unit tests, because we will rewrite it, which means that the signatures of the methods will change and new classes will appear. So why write tests that you have to throw away? I want to make a reservation that for this kind of refactoring we still need testing, but it is better to use higher-level acceptance tests . We will consider this case separately.

1. Complex code without dependencies. These are some algorithms or business logic. Well, these are important parts of the system, we are testing them.
2. Not very complicated code with dependencies. This code connects different components. Tests are important to clarify exactly how the interaction should occur. The reason for the loss of the Mars Climate Orbiter on September 23, 1999 was a human-software error: one unit of the project counted “in inches” and the other “in meters”, and this was clarified after the loss of the device. The result could be different if the teams tested the “seams” of the application.

Follow the same style of writing the body of the test

class CalculatorTests
{
	public void Sum_2Plus5_7Returned()
	{
		// arrange
		var calc = new Calculator();
		// act
		var res = calc.Sum(2,5);
		// assert
		Assert.AreEqual(7, res);	
	}
}

class CalculatorTests
{
	public void Sum_2Plus5_7Returned()
	{
		Assert.AreEqual(7, new Calculator().sum(2,5));	
	}
}

Test one thing at a time

Addiction Fighting

public class AccountManagementController : BaseAdministrationController
{
	#region Vars
	private readonly IOrderManager _orderManager;
        private readonly IAccountData _accountData;
        private readonly IUserManager _userManager;
        private readonly FilterParam _disabledAccountsFilter;
        #endregion
        public AccountManagementController()
        {
            _oms = OrderManagerFactory.GetOrderManager();
            _accountData = _ orderManager.GetComponent();
            _userManager = UserManagerFactory.Get();
            _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true);
        }
}

public class AccountManagementController : BaseAdministrationController
{
        #region Vars
        private readonly IOrderManager _oms;
        private readonly IAccountData _accountData;
        private readonly IUserManager _userManager;
        private readonly FilterParam _disabledAccountsFilter;
        #endregion
        public AccountManagementController()
        {
            _oms = OrderManagerFactory.GetOrderManager();
            _accountData = _oms.GetComponent();
            _userManager = UserManagerFactory.Get();
            _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true);
        }
        /// 

        /// For testability
        /// 
        /// 
        /// 
        public AccountManagementController(
            IAccountData accountData,
            IUserManager userManager)
        {
            _accountData = accountData;
            _userManager = userManager;
            _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true);
        }
}

Fakes: stubs & mocks

Headquarters

[Test]
public void LogIn_ExisingUser_HashReturned()
{
	// Arrange
	OrderProcessor = Mock.Of();
	OrderData = Mock.Of();
	LayoutManager = Mock.Of();
	NewsProvider = Mock.Of();
	Service = new IosService(
		UserManager,
		AccountData,
		OrderProcessor,
		OrderData,
		LayoutManager,
		NewsProvider);
	// Act
	var hash = Service.LogIn("ValidUser", "Password");
	// Assert
	Assert.That(!string.IsNullOrEmpty(hash));
}

Mok

[Test]
public void Create_AddAccountToSpecificUser_AccountCreatedAndAddedToUser()
{
    // Arrange
    var account = Mock.Of();
    // Act
    _controller.Create(1, account);
    // Assert
    _accountData.Verify(m => m.CreateAccount(It.IsAny()), Times.Exactly(1));
    _accountData.Verify(m => m.AddAccountToUser(It.IsAny(), It.IsAny()), Times.Once());
}

Health testing and behavior testing

Condition testing

Interaction testing

Insulation Frameworks

• Bicycles are already written before us
• Many interfaces are not so easy to implement with half a kick
• Our self-made fakes may contain errors
• This is additional code that will have to be supported.

Architecture under test

public AccountManagementController(
    IAccountData accountData,
    IUserManager userManager)
{
    _accountData = accountData;
    _userManager = userManager;
    _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true);
}

Constructor injection

Factory Injection

public class UserManagerFactory
{
    private IUserManager _instance;
    /// 

    /// Get UserManager instance
    /// 
    /// IUserManager with configuration from the configuration file
    public IUserManager Get()
    {
        return _instance ?? Get(UserConfigurationSection.GetSection());
    }
    private IUserManager Get(UserConfigurationSection config)
    {
        return _instance ?? (_instance = Create(config));
    }
    /// 

    /// For testing purposes only!
    /// 
    /// 
    public void Set(IUserManager userManager)
    {
        _instance = userManager;
    }
}

Factory spoofing

Override the local factory method

public class Calculator
{
    public double Multipy(double a, double b)
    {
        var multiplier = new Multiplier();
        return multiplier.Execute(a, b);
    }
}
public interface IArithmetic
{
    double Execute(double a, double b);
}
public class Multiplier : IArithmetic
{
    public double Execute(double a, double b)
    {
        return a * b;
    }
}

public class Calculator
{
    public double Multipy(double a, double b)
    {
        var multiplier = CreateMultiplier();
        return multiplier.Execute(a, b);
    }
    protected virtual IArithmetic CreateMultiplier()
    {
        var multiplier = new Multiplier();
        return multiplier;
    }
}
public class CalculatorUnderTest : Calculator
{
    protected override IArithmetic CreateMultiplier()
    {
        return new FakeMultiplier();
    }
}
public class FakeMultiplier : IArithmetic
{
    public double Execute(double a, double b)
    {
        return 5;
    }
}

Tested VS OOP Architecture

Serious Security Requirements

Performance

• Think with interfaces, not with classes, then you can always easily replace real implementations with fakes in test code
• Avoid direct instantiation of objects inside methods with logic. Use factories or dependency injection . In this case, using an IOC container in a project can greatly simplify your work.
• Avoid calling static methods directly
• Avoid constructors that contain logic: it will be difficult for you to test this.

Work with legacy code

Architecture is testable

Architecture is not testable

Test support

1. Error in the production code: this is a bug, you need to get it in the bug tracker and fix it.
2. Bug in the test: apparently, the production code has changed, and the test is written with an error (for example, it tests too much or not what was needed). It is possible that before he went wrong. Understand and repair the test.
3. Change of requirements. If the requirements have changed too much, the test should fall. This is correct and normal. You need to deal with the new requirements and fix the test. Or delete if it is no longer relevant.

How to measure progress

1. Number of bugs in new releases (including regression)
2. Code coverage

• NCover
• dotTrace
• Built-in Studio Test Coverage

Test first?

Read on the topic