ria 06 & 07 - unit testing in detail

STAATLICHANERKANNTEFACHHOCHSCHULE

Author: Dip.-Inf. (FH) Johannes HoppeDate: 17.11.2010

01.12.2010

STUDIERENUND DURCHSTARTEN.

STAATLICHANERKANNTEFACHHOCHSCHULE

RIA – Rich Internet Applications

Author: Dip.-Inf. (FH) Johannes HoppeDate: 17.11.2010

01.12.2010

Unit Tests in General

0109.04.2023

Folie 3

Unit Tests in General

Dependencies

› Every meaningful piece of software has dependenciesto other pieces of software

09.04.2023

Folie 4

SoftwareA

SoftwareB

SoftwareC

Unit Tests in General

Dependencies

› But usually software is tightly coupled to other software› Tightly coupled software is untestable!

09.04.2023

Folie 5

SoftwareA

SoftwareB

SoftwareC

Unit Tests in General

Dependencies

› We will concentrate on two types of dependencies:

1. A dependency by parameters:ClassA { Method(ClassB b) {…}}

09.04.2023

Folie 6

SoftwareA

SoftwareB

SoftwareC

Unit Tests in General

Dependencies

2. A dependency by the internal use of the “new” keyword:Class A { Method() { var c = new ClassC();}}

09.04.2023

Folie 7

SoftwareA

SoftwareB

SoftwareC

Unit Tests in General

Dependencies – Solution

› Our golden tools:

Interfaces & Dependency Injection

09.04.2023

Folie 8

SoftwareA

ISoftwareB

ISoftwareC

SoftwareB

SoftwareC

Unit Tests in General

Interfaces

› Interfaces are blueprints that describe a real implementation› Method are going to be independent

from the concrete implementation of the parameter:

ClassA { Method(ISoftwareB b) {…}}

09.04.2023

Folie 9

SoftwareA

ISoftwareB

ISoftwareC

SoftwareB

SoftwareC

Unit Tests in General

Dependency Injection

› We completely avoid the usage of the “new” keyword› Instead, we are “injecting” the required instance

from outside by using Interfaces› “Poor Man’s”-DI through constructor (works for UT, but is an anti-pattern!)› by a framework (here: Unity Application Block):

ClassA { [Dependency] public InterfaceC C { private get; set; }}

09.04.2023

Folie 10

Unit Tests in General

Loosely Coupled

1. If all dependencies are hidden by Interfaces2. We must not always use real-live objects3. We could also “cheat” with any object we want

(as long as it is implementing the interface)

Unit Testing!!

09.04.2023

Folie 11

Unit Tests in General

09.04.2023

Folie 12

Definitions

› SUT == System Under Test› Needs to be “fooled” so that it things it is talking with real collaborators

› Dummy › Objects passed around but never actually used› Used to fill required parameters in Unit Tests

› Fake› Objects with working implementations, but not suitable for production

(e.g. in memory database with hardcoded data)› Often used in software prototypes› Should not be used in unit tests, too

Unit Tests in General

09.04.2023

Folie 13

Definitions

› Stubs › Simple hand-written test-objects› Set up the environment for the Unit Test by returning hardcoded values

can be used for:

state verification

Determine whether the exercised method worked correctly byexamining the state of the SUT and its collaboratorsafter the method was exercised.

Unit Tests in General

09.04.2023

Folie 14

Definitions

› Mocks› More complex test-objects› pre-programmed with expectations which form a specification of the calls they

are expected to receive*

can be used for:

behavior verification

Determine whether the exercised method worked correctly bychecking if the SUT made thecorrect calls on the collaborators.

(* according to the definition of Martin Fowler)

Unit Tests in General

Definitions

› Many people (including me) are mixing the terms stub, fake and mock

› Mocking frameworks› Can create Mocks with a lot of magic inside› Can be used to build simple stubs, too!

09.04.2023

Folie 15

Unit Tests in General

Glossary

› MsTest – The unit testing framework that comes with Visual Studio

› Nunit – A quite popular unit testing framework which is open sourcewww.nunit.org

› Moq – A mocking framework that easy to use because of the lambda expression syntax

www.moq.me

09.04.2023

Folie 16

Unit Tests in General

Questions

?

09.04.2023

Folie 17

Review of our first Unit Test

0209.04.2023

Folie 18

Unit Tests

09.04.2023

Folie 19

Ho

w?

Review of our first Unit Test

Explanation of Code

09.04.2023

Folie 20

Review of our first Unit Test

Dependencies

09.04.2023

Folie 21

WebNoteRepository

IWebNote

IObjectSet<Note>

Review of our first Unit Test

Dependencies

IWebNote – Entity Framework:

IWebNote – by our own Mock:

09.04.2023

Folie 22

WebNoteRepository

IWebNote

Review of our first Unit Test

09.04.2023

Folie 23

WebNoteRepository

IWebNote

IObjectSet<Note>

Dependencies

IObjectSet<Note> – Entity Framework:

IObjectSet<Note> – by our own Mock:

Chaining

› Real live: by poor man’s DI

› Unit Test: automatically by the class WebNoteBaseRepositoryTest› From which we are inheriting in our UT

Review of our first Unit Test

09.04.2023

Folie 24

Chaining

Unit Tests in General

09.04.2023

Folie 25

Mocked Repository

Base class from which we are inheriting

Required to prepare the mock

Unit Tests

Your tasks from last week:

› Try to write your first set of unit tests› Work together with you neighbor (2 persons, one team)› Use the Mock-Framework “Moq” from www.moq.me› Implement:

AddNoteTest, EditNoteTest, DeleteNoteTest DeleteNoteShouldThrowExceptionTest GetNoteShouldNotCallSaveChangesTest 6 Tests for the Controller

09.04.2023

Folie 26

Unit Tests

0309.04.2023

Folie 27

Unit Tests

Tests: only with stubs

09.04.2023

Folie 28

Unit Tests

09.04.2023

Folie 29

Unit Tests

09.04.2023

Folie 30

Unit Tests

09.04.2023

Folie 31

Unit Tests

09.04.2023

Folie 32

Unit Tests

09.04.2023

Folie 33

Unit Tests

Tests: with Mocks

09.04.2023

Folie 34

Unit Tests

09.04.2023

Folie 35

Unit Tests

09.04.2023

Folie 36

Unit Tests

09.04.2023

Folie 37

Unit Tests

09.04.2023

Folie 38

behavior verification!

THANK YOUFOR YOUR ATTENTION

09.04.2023

Folie 39