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.

Pragmatic Unit Testing Pluralsight course

My new course Building a Pragmatic Unit Test Suite for Pluralsight went live. Building a Pragmatic Unit Test Suite Unit testing can be applied differently. Like many other things in programming, there are a lot of ways to mess up with it. It’s important to differentiate unit testing techniques that help bring confidence in your code base correctness from techniques that can potentially have a devastating effect on your entire test suite.

Unit testing anti-patterns: Structural Inspection

Growing Object-Oriented Software, Guided by Tests Without Mocks

This is a review of the Growing Object-Oriented Software, Guided by Tests book (GOOS for short) in which I’ll show how to implement the sample project from the book in a way that doesn’t require mocks to be tested. Growing Object-Oriented Software, Guided by Tests Without Mocks Let me first explain why I’m doing a review of this book. If you read this blog regularly, you probably noticed that I’m pretty much against using mocks in tests.

Pragmatic integration testing

The topic described in this article is part of my Unit Testing Pluralsight course. When trying to break down unit testing, the bigger picture stays incomplete if you overlook the subject of integration testing. In this post, we’ll discuss how to make the most out of your integration tests with pragmatic integration testing. Integration tests are tests that, unlike unit tests, work with some of the volatile dependencies directly (usually with the database and the file system).

Pragmatic unit testing

The topic described in this article is part of my Unit Testing Pluralsight course. This post is about pragmatic unit testing: how to get the most out of your unit test suite. Pragmatic unit testing: black-box vs white-box Pragmatic unit testing is about investing only in the tests that yield the biggest return on your effort. In the previous posts, we discussed what traits a valuable test possess (high chance of catching a regression, low chance of producing a false positive, fast feedback) and how various styles of unit testing (functional, state verification, collaboration verification) differ in terms of their value proposition.

Styles of unit testing

The topic described in this article is part of my Unit Testing Pluralsight course. In this post, I’ll describe different styles of unit testing and compare them in terms of their value proposition. Styles of unit testing and their value proposition There are 3 major styles of unit testing. The first one is functional, where you feed an input to the system under test (SUT) and check what output it produces:

Unit tests value proposition

The topic described in this article is part of my Unit Testing Pluralsight course. I’m starting a new series which will be devoted to the topic of unit testing. In it, I’ll try to define what a valuable test is and show how the use of mocks fits into this picture. I’ll also describe the approach that I think has the best return of investments in terms of the value it provides.