1 / 20

Taking your tests to the next level with Mocks

Taking your tests to the next level with Mocks. Where are we going today?. Learning the P’s & Q’s Walk through the evolution of testing Learn to break dependencies with Mocks Learn how testing changes your code design. Learning the Terms. Mocks vs. Stubs AAA vs. Record/Replay semantics

bobby
Download Presentation

Taking your tests to the next level with Mocks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Taking your tests to the next level with Mocks

  2. Where are we going today? Learning the P’s & Q’s Walk through the evolution of testing Learn to break dependencies with Mocks Learn how testing changes your code design

  3. Learning the Terms • Mocks vs. Stubs • AAA vs. Record/Replay semantics • Type of Mocks • Strict Mocks – Strict replay semantics • Dynamic Mocks – Loose replay semantics • Partial Mocks – Mock only requested methods • With MockRepository Instance vs Static MockRepository • AutoMocking Containers

  4. Why Should I Mock • Test in Isolation • No fear of external resources breaking • Web Services • Database’s • Test edge conditions • Easily force failures • Simulation of Objects • Reduces overhead

  5. Unit Test vs. Integration Test • What is a ‘Unit Test’ • The smallest testable part of an application. The code should be tested in isolation by removing dependencies in order to have reliable tests. • What is a ‘Integration Test’ • End to end testing either within a module or application. Code for the tests are coupled and tested as a whole unit.

  6. Dependency Barrier Breaking Dependencies with Mocks Tests without Mocks Tests with Mocks

  7. In the Beginning…

  8. Then came…. UserLogin userLogin = ObjectFactory.GetInstance<UserLogin>(); // 1 - Need to find a username that is NOT already in use by another user // 2 - Need to find a password that is complexe enough User createdUser = userLogin.CreateUser("SomeUnusedUsername", "S0meP@ssw0rd", "FirstName", "LastName"); // Need to do our asserts on evertying …

  9. Failure Points with out Mocks

  10. Now we have…. varmocker = newMockRepository(); varmockRepository = mocker.PartialMock<ValidationRepository>( new ConfigurationReader(), null ); mockRepository.Expect( x => x.ExecuteDataSet( command, new SqlParameter[ 0 ] ) ).IgnoreArguments().Return( dataSet).Repeat.Once(); varresult = mockRepository.HasViolationForVisitDateTimeChanged( 12, serverDate, serverTime ); Assert.That( result, Is.Not.Null ); Assert.That( result.Success, Is.EqualTo( true ) );

  11. Failure Points with Mocks

  12. Example 1 • We would like to be able to create a new user for our system. • Requirements • All valid data must be provided • Password must meet complexity standards • Username must not already exist

  13. Lets Code • Review a test with NO MOCKS • Review pain points • Review same test WITH MOCKS • Review pain points

  14. Example 2 • If the user forgets their password we would like to email it to them • Requirements • Username must exist • User must answer challenge question correctly • Send email to user with valid information

  15. Lets Code • Create a test where we want our email service to fail • Review pain points

  16. Example 3 Demo partial mocking abilities Lets code….

  17. Lets Code • Create a test where we want our email service to fail • Review pain points

  18. Example 4 Redoing Example 2 but with an Automocking Container Lets code….

  19. Thoughts on Design for Testability • Interfaces driven development • Makes us use contracts • Single Responsibility Principle • Forces us to think about what it is we want each ‘thing’ to do. • Separation of Concerns • Allows us to de-couple our applications. • No more ‘be all, end all’ objects • Inversion of Control/Dependency Injection • Flipping our design our its head • Allows us to simply mock dependencies as well

  20. Mocking Tips/Gotcha’s Can only mock ‘public’ classes or interfaces Can only mock interfaces, delegates and virtual methods of classes! Cannot mock sealed classes.

More Related