4. Unit Tests in General
Dependencies
› Every meaningful piece of software has dependencies
to other pieces of software
30.01.2015
Folie 4
SoftwareA
SoftwareB
SoftwareC
5. Unit Tests in General
Dependencies
› But usually software is tightly coupled to other software
› Tightly coupled software is untestable!
30.01.2015
Folie 5
SoftwareA
SoftwareB
SoftwareC
6. Unit Tests in General
Dependencies
› We will concentrate on two types of dependencies:
1. A dependency by parameters:
ClassA { Method(ClassB b) {…}}
30.01.2015
Folie 6
SoftwareA
SoftwareB
SoftwareC
7. Unit Tests in General
Dependencies
2. A dependency by the internal use of the “new” keyword:
Class A {
Method() {
var c = new ClassC();
}}
30.01.2015
Folie 7
SoftwareA
SoftwareB
SoftwareC
8. Unit Tests in General
Dependencies – Solution
› Our golden tools:
Interfaces & Dependency Injection
30.01.2015
Folie 8
SoftwareA
ISoftwareB
ISoftwareC
SoftwareB
SoftwareC
9. 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) {…}}
30.01.2015
Folie 9
SoftwareA
ISoftwareB
ISoftwareC
SoftwareB
SoftwareC
10. 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; }
}
30.01.2015
Folie 10
11. Unit Tests in General
Loosely Coupled
1. If all dependencies are hidden by Interfaces
2. We must not always use real-live objects
3. We could also “cheat” with any object we want
(as long as it is implementing the interface)
Unit Testing!!
30.01.2015
Folie 11
12. Unit Tests in General
30.01.2015
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
13. Unit Tests in General
30.01.2015
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 by
examining the state of the SUT and its collaborators
after the method was exercised.
14. Unit Tests in General
30.01.2015
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 by
checking if the SUT made the
correct calls on the collaborators.
(* according to the definition of Martin Fowler)
15. 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!
30.01.2015
Folie 15
16. 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 source
www.nunit.org
› Moq –A mocking framework that easy to use because of the lambda
expression syntax
www.moq.me
30.01.2015
Folie 16
17. Unit Tests in General
Questions
?
30.01.2015
Folie 17
18. Review of our first Unit Test
02
30.01.2015
Folie 18
20. Review of our first Unit Test
Explanation of Code
30.01.2015
Folie 20
21. Review of our first Unit Test
Dependencies
30.01.2015
Folie 21
WebNoteRepository
IWebNote
IObjectSet<Note>
22. Review of our first Unit Test
Dependencies
IWebNote – Entity Framework:
IWebNote – by our own Mock:
30.01.2015
Folie 22
WebNoteRepository
IWebNote
23. Review of our first Unit Test
30.01.2015
Folie 23
WebNoteRepository
IWebNote
IObjectSet<Note>
Dependencies
IObjectSet<Note> – Entity Framework:
IObjectSet<Note> – by our own Mock:
24. 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
30.01.2015
Folie 24
25. Chaining
Unit Tests in General
30.01.2015
Folie 25
Mocked Repository
Base class from which we are inheriting
Required to prepare the mock
26. 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
30.01.2015
Folie 26