Tag Mocks
Exposing private state to enable unit testing
Last time, we talked about making private methods public in order to enable unit testing. It’s not the only way people expose implementation details to the outside world for unit testing purposes, though. Today, we’ll look at a similar anti-pattern: exposing private state.
Interfaces for repositories: do or don't?
Today’s topic is about interfaces for repositories. Should you introduce them? Or maybe it’s better to use repositories as is? Let’s see.
When to include external systems in testing scope
Should you always mock out your database? Or should you include it in the unit/integration testing scope? What about other external systems? This post is based on my Pluralsight course about Pragmatic Unit Testing. Two types of external dependencies When it comes to external dependencies (dependencies outside the process that hosts your application, such as a database, a 3rd party system, etc.), there’s no single guideline regarding how to work with them in tests.
Verifying collaborations at the system edges
Last week I wrote about when to use mocks. In this post, I’d like to outline a specific guideline which comes into play when you start working with mocks: verifying collaborations at the system edges. This article is based on my recent Pluralsight course about Pragmatic Unit Testing. Verifying collaborations at the system edges The use of mocks goes hand in hand with the style of unit testing which I call collaboration verification.
Stubs vs Mocks
In this article, I’d like to discuss the differences in using stubs and mocks and show how you can abandon using mocks even in the cases where you need to verify that objects interact with each other correctly.
Integration testing or how to sleep well at nights
Unit testing is good at checking the correctness of your code in isolation, but it’s not a panacea. Only integration tests can give us confidence that the application we develop actually works as a whole. They are also a good substitute for mocks in the cases where you can’t test important business logic without involving external dependencies.
-
Integration testing or how to sleep well at nights
How to do painless TDD
Last week, we nailed the root cause of the problems, related to so-called test-induced damage - damage we have to bring into our design in order to make the code testable. Today, we’ll look at how we can mitigate that damage, or, in other words, do painless TDD.
