Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with substitute code. These substitutes are called stubs and shims and are under the control of your tests. Microsoft Fakes is ideal when you need to test legacy or “legacy” code that is either restricted for refactoring or “refactoring” practically means rewriting and cost you a lot.
3. Agenda
Testing in software
Unit testing
• Why unit tests
• Unit tests conventions
• Dependencies, Coupling
Microsoft Fakes
• How does it help
• How does it work
• Stubs
• Shims
• How Do I choose
Q&A
5. Page 5
Strategy Description Visual Studio Tooling
Exploratory
Test
Tester tries to think of possible scenarios not covered by other test strategies and
tests. Useful when engaging users with the testing and observing their (expected)
usage of the system. There are no predefined tests.
Exploratory testing with Microsoft
test Manager (MTM)
Integration
Test
Testing different solution components working together as one. Visual Studio Unit Test features
Load Test Testing under load, in a controlled environment. Visual Studio Load Test Agent
Regression
Test
Regression testing ensures that the system still meets the quality bar after changes
such as bug fixes. Uses a mixture of unit tests and system tests.
Automated testing with MTM
Smoke Test Smoke testing is used to test a new feature or idea before committing the code
changes.
System Test Testing of the entire system against expected features and non-functional
requirements.
Visual Studio Lab Management
Unit Test A test of the smallest unit of code (method / class, and so on) that can be tested
in isolation from other units.
Visual Studio Test Explorer
Unit Test Frameworks
User
Acceptance
Test
Toward the end of the product cycles users are invited to perform acceptance
testing under real-world scenarios, typically based on test cases.
Automated testing with MTM
Testing types
7. Page 7
Unit testing?
• Unit testing is a software testing method by which individual units of
source code, are tested to determine whether they are fit for use.
• “Units of source code” are methods/functions. The unit test is simply
a method/function that calls another method and determines that
the later works correctly.
• How we can verify that our GetEmployeeById(int id) works correctly? Isolation, a
mechanism that will isolate the code under test, and resolve all dependencies
• Unit tests naming conventions:
• MethodName_StateUnderTest_ExpectedBehavior
• WithdrawMoney_InvalidAccount_ExceptionThrown
• MethodName_ExpectedBehavior_StateUnderTest
• Should_ExpectedBehavior_When_StateUnderTest
8. • Make sure the code works
• Refactor with confidence
• Support emerging design
• Reducing the cost of fixing bugs by fixing them earlier, rather than later
• Get a quick understanding of the quality of code
Page 8
Why Unit Tests?
9. Unit tests conventions
• Unit tests naming conventions (there are many)
• MethodName_StateUnderTest_ExpectedBehavior
• WithdrawMoney_InvalidAccount_ReturnsFalse()
• Login_InvalidCredentials_ReturnsErrorMessage()
• MethodName_ExpectedBehavior_StateUnderTest
• WithdrawMoney_ReturnsFalse_InvalidAccount ()
• The 3A of unit testing – Arrange, Act, Assert
• Arrange: Set up the object to be tested. We may need to surround the object with collaborators.
For testing purposes, those collaborators might be test objects (mocks, fakes, etc.) or the real
thing.
• Act: Act on the object (through some mutator). You may need to give it parameters (again,
possibly test objects).
• Assert: Make claims about the object, its collaborators, its parameters, and possibly (rarely!!)
global state.
Page 9
11. • In software engineering, coupling is the manner and degree of
interdependence between software modules. Much of unit tests is
solving dependencies and coupling.
• Practicing unit tests will improve code quality on the long run.
Some principles and patterns must be employed to improve
testability.
• Single responsibility principle (SRP)
• Open Closed Principle (OCP)
• Dependency Inversion Principle (DI)
• Don’t Repeat Yourself (DRY)
• You Aren’t Going to Need It (YAGNI)
Page 11
Dependencies, Coupling
13. • Microsoft Fakes is a framework that enables us to isolate the code we are
testing by replacing dependencies of our code with stubs or shims.
• The Fakes Framework in Visual Studio 2012 is the next generation of Moles
& Stubs. (Read: migrate not upgrade)
• Available in VS 2012/2013 Ultimate
• Works with .Net framework 2.0 and Above
• Newest version available with VS 2015 Enterprise
Page 13
What is the Microsoft Fakes Framework?
14. • Allows us to quickly implement doubles to support testing in isolation
• Allows us to decouple from slow running dependencies like DB, file system,
message system.
• Decoupling allows us to write order independent unit tests
• Stage data in test methods, not in a DB.
• One unit test failure will not cause a chain reaction
• No need to reset a database to a golden state.
• Allows us to intercept calls to dependencies we do not control.
Page 14
How the Fakes framework helps
15. • In Microsoft Fakes, the developer must right-click the assembly
reference they wish to mock and select Add Fakes Assembly. This will
generate a new assembly that must be referenced to create the fake
objects.
Page 15
Generated code
19. • For every public type in the referenced assembly which are included
into shim-based faking via configuration, the Microsoft Fakes
mechanism generates a shim class. The type name is the same as the
original type, with "Shim" as a prefix.
Page 19
Shims (all instances)
20. • Shim methods can be injected per instance of an object.
In this example myClass1.MyMethod() will return 5 while
myClass2.MyMethod() will return 10;
Page 20
Shims (one instance)
21. • Shims must be used within a ShimsContext.Create() using statement.
• If need to execute original code a call to
ShimsContext.ExecuteWithoutShims must be placed inside the
shimmed method.
Page 21
Shims Context and Behavior
24. • Stubs
• Helps if you’re interface-driven
• Creates default() implementations of an interface
• including properties & methods
• Shims
• <magic/>
• Substitute hard-coded types with
*something else* at runtime
Dae Page 24
Stubs and Shims
25. • Stubs
• If you’ve got interfaces already
• You’re building from scratch
• If you want to save yourself some typing
• You aren’t battling “sealed” and “static” keywords
• Shims
• Stuff is hopelessly stuck together
• Stuff is hopelessly non-testable
• You’re supporting legacy code
• You are Ninja
• Shims are not a long-term solution (except when there is no other
solution).
Page 25
Stubs and Shims
MY Practical definitions
SRP – designing classes so they do one thing well keeps the class simple. Simple classes are easier to test. Code smell large classes and large methods.
OCP – Design classes to be resilient in the face of change. For example using abstract methods on base classes lets add behavior without changing existing code. Code smell frequently adding a case to a switch statement or If then Else If
DI - high level classes are not working directly with low level classes, they are using interfaces as an abstract layer. Why – Easier to test in isolation! Code smell : “Newing up classes”
DRY – Don’t repeat yourself – code and test it once reuse many times. Less code to write – less code to change (1 spot)
YAGNI – Don’t write code until you need it. Remove unused code and corresponding tests – greatest refactor you do removes code.
