Unit Testing Full@

• Advanced Object Oriented Design• Unit Testing Principles• S.O.L.I.D• Refactoring

Unit Testing Purpose

Proof that our classes work properly

If we repaired the bug in the code, we would like to be sure it won’t happen again

Isolate each part of the program and show that the individual parts are correct.

Encourages programmers to make changes to the code since it is easy for the programmer to check if the piece is still working properly.

Unit testing allows the programmer to re-factor code and make sure the module still works correctly (i.e. regression testing).


If we did break something, we would like to know about it ASAP and not wait until QA finds the bug for us the sooner a bug is detected, the simpler and less costly it is to fix

If we break something we would like to know how it worked originally; unit testing provides a sort of "living document".


Enforce higher quality code because of SOLID, CLEAN code and OOP principles that is necessary for successful unit test creation.

This results in loosely coupled code, minimized dependencies in the system, etc.


Unit-testing will not catch every error in the program. It will not catch integration errors It will not catch performance problems It will not catch system-wide issues.

Disadvantages

Not all code may be covered with Unit Tests. For example if class has tight coupled instances

Disadvantages

Aa a supplement to development, additional time required for implementation and support of unit test.

Test Driven Development is not Unit Testing

TDD Disadvantages

Big time investment, additional complexity, architecture impact, much more thinking ;)

Shallow (long) Learning Curve

ReSharper

• Save time on compilation, locating & fixing errors – ReSharper instantly detects and highlights errors in your code and allows automatic corrections for most errors – much less possibilities for bugs

Example:

ReSharper

• Automate routine tasks – Quickly create methods, properties, variables or classes from their usages, generate constructors, properties, delegating and equality members; implement and override members; and much more

Example:

ReSharper

• Get useful hints right when you need them – IntelliSense, including code completion and quick parameter information

Example:

ReSharper

• Improve your coding practices – Change is easy — with solution-wide, cross-language refactorings (nearly 6 times as many as in Microsoft Visual Studio, and growing), additional automated code transformations, and code cleanup Example:

ReSharper

• Navigate to any corner of your solution – Reach any part of your code within seconds, with dozens of smart navigation and search features

Example:

ReSharper

• Handle multi-language solutions with ease – Refactorings, navigation and search, and coding assistance work across C#, VB.NET, XAML, ASP.NET, TypeScript, JavaScript, CSS and more languages – Support all languages in the same solution – CSLP – TypeScript / HTML / C# / JavaScript

Example:

ReSharper

• ReSharper provides a unit test runner that helps you run and debug unit tests based on NUnit, xUnit.net, MSTest, QUnit and Jasmine. You can explore tests, group them in different ways, break them down into individual sessions, see test output and navigate to source code from stack traces.

ReSharper

• Analyzing code coverage with dotCover• You can easily discover the degree to which the

code of your solution is covered with unit tests.

ReSharper

• For those who are working with Visual Studio Code have to use TSLint plugin to review, analyze code

• TSLint checks your TypeScript code for readability, maintainability, and functionality errors.

Example:

Examples of when you should refactor the code before creating unit tests

Tested Method / Class (Unit) has more than one responsibility

Private Class / Methods. (Possible with using reflection, but will significantly reduce the performance of tests)

Method / Class don’t allow dependency injection, for example tightly coupled instances [new object();]

All dependencies are explicitly passed in constructor/method parameters or properties. If it is not passed, it should not be used.

Must avoid hidden dependencies

Static methods (like DateTime.Now)

Singletons

OOD, CLEAN Code and SOLID Principles

OOD principles we must use in order to get testable application Encapsulation

• Hide methods / properties…but REMEMBER private objects shouldn't be tested

Abstraction

• Domain analysis• Legacy analysis• Levels of abstraction

Inheritance

• Interfaces not concretes• Code reuse

Polymorphism

S.O.L.I.D. - Five basic principles of object-oriented programming and design. The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible.


Single responsibility principle - a class should have only a single responsibility Makes clear the purpose of each class, increases maintainability, and promotes code reuse

Refactoring


Open / closed principle – should be open for extension, but closed for modificationincreases the maintainability and reusability of code

If you will add new functionality, create a new class extending an existing one, rather than changing it

Refactoring


Liskov substitution principle - objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program - It gives us Code reuse

If you create a new class extending an existing class, make sure it's completely interchangeable with its base


Interface Segregation Principle

Refactoring


Dependency Inversion Principle - Dependency Injection provides a means of injecting dependencies into an object as opposed to hard coding the dependencies within the object itself. Classes designed in this matter lend themselves to both unit testing via mocking or stubbing


Design Patterns

Singleton

Factory

Builder

Object Pool

Command

Mediator

Observer

Strategy

Visitor

Adapter

Decorator

Proxy

Structural Behavioral Creational

Unit Tests Code coverage

Unit Tests should cover upper and lower boundary conditions, including exceptions



Exclude test projects from code coverage statistics


Why exclude non test projects

Unit Tests

Creating Unit Tests (without depended objects, no mock objects needed)

Unit Tests

Introducing Unit Tests with Mock objects

Most of the unit tests requires using of MOCK objects. For example if you have provider to test and you don’t have connection any time you run the test or you don’t want to be depend on the connection. In order to create MOCK object we must use interface. We can create stub objects instead of mock – reduce performance, much more complicated and serves just for state not behaviour (cant return results)

Unit Tests with Mocks

Depend upon Abstractions. Do not depend upon concretions.

Providing SUT with Mocking, Faking, Stubbing

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Providing SUT with Mocking, Faking, Stubbing

Creating Mock Object

• The first step – create data on the mocking (properties, etc.)

• The second step - create expectations on the mock object. The expectations indicate which methods should be called on the mocks when the SUT is exercised.

CODE UNIT TEST

CODE UNIT TEST

CODE UNIT TEST

CODE UNIT TEST

CODE UNIT TEST

Mocking Objects https://github.com/Moq/moq4

Mocking is an integral part of unit testing. Although you can run your unit tests without use of mocking but it will drastically slow down the executing time of unit tests and also will be dependent on external resources.

The mock object knows in advance what is supposed to happen during the test (e.g. which of its methods calls will be invoked, etc.) and the mock object knows how it is supposed to react (e.g. what return value to provide). The mock will indicate whether what really happens differs from what is supposed to happen. A custom mock object could be coded for the expected behavior of each test case (see example)

In some cases we can use FAKE or STUB objects instead of Mock. For example concrete class don’t have an interface and we can’t mock this object. So we can create FAKE object and use it for testing. In this case we will dramatically reduce test performance and FAKE object has MUCH more less possibilities for testing.

Mock objects are simulated objects that mimic the behavior of real objects in controlled ways.

https://github.com/Moq/moq4

VS 2013 Code Coverage Tool

Example

Documents

Unit Testing Full@