The secret world of testing without mocking: domain-driven design, fakes, and other patterns to simplify testing in a microservice architecture

Much has been said about mocks, the controversial, Swiss army knife of test doubles: Don't use them too much (source) (source) Know when to use them at all (source) Don't use them to test implementation detail (source) Don't mock types you don't own (source) Only mock classes when dealing with legacy code (source) Don't mock complex interfaces (source) (source) ...the list goes on. For a tool so easy to misuse, we're using it quite a lot. Mockito is one of the most depended-upon Java libraries in the world . While "mocking" is an abstract concept, for the remainder of this post I'll use the term mock to refer specifically to a mock or stub configured by way of a mocking library like Mockito. Likewise, when I refer to Mockito, I really mean any mocking library; Mockito just stands out because it has a welcoming API and is–no doubt as a consequence–measurably very popular. I was there too once, a frequent Mockito user, perhaps

What the health!? Implementing health probes for highly available, self-healing, global services

Health probes are essential to running a highly available service, yet they are surprisingly tricky to implement without inadvertently making your uptime worse . Even popular frameworks like Spring Boot (until recently 1 ) used unfortunate defaults that may accidentally encourage a hurried developer to fall into some surprising traps that reduce their services' uptime. Over time, my team has come up with a set of rules to avoid these traps . I'll lay them out first succinctly, and then explain them in detail along with the model we use that embodies them. Don't overload health endpoints – favor more over reuse Keep logic out of monitors – put in endpoints Be very conservative when determining if un healthy Run health checks in background – not on demand If your in a hurry , you can skip straight to the summary . This post may use Kubernetes terms like "container" and "probe", but these ideas can be applied to services running on any

Asynchronous denormalization and transactional messaging with MongoDB change streams

MongoDB provides a very useful set of abstractions for building a reliable service. I've found in practice, few databases can rival its indexing, resiliency (automated failover, even between regions; sharding) and consistency (primary and secondary reads) characteristics and their corresponding client library support. Of course, for all that, you give up flexible transaction boundaries (among other things). With a traditional RDBMS, you can describe the data you need to fit your business model, and worry about isolating writes among different tables later. With document-stores like MongoDB, you must design your documents around sensible isolation boundaries and query patterns. So, when joins are needed, you're typically advised to denormalize the joined data in order to keep queries to a single document, but at the same time MongoDB provides little facilities for denormalizing data! As of MongoDB 4.0, there are multi-document transactions, though they come at a performance

Kubernetes Distilled, Part 1: Deployments and Services

Kubernetes documentation is thorough, and you should read it when you have the time. Until then, this is a condensed overview aimed at developers using a Kubernetes platform that should get you comfortable enough, quickly enough, to have enough of a foothold to experiment and understand the official documentation where more detail is needed. I'm not an expert, so YMMV. I assume you are familiar with Docker, linux containers, and with the basic premise of Kubernetes: you've got images and want to run them reliably, with minimal manual intervention. As a tradeoff, you must learn and invest in Kubernetes' abstractions. Overview Kubernetes (or "k8s"–which is to Kubernetes as a11y is to accessibility) runs on top of a cluster of nodes , where a node is machine as in physical or virtual machines, and a cluster is a datacenter or part of one. Nodes are the resources k8s uses to run its Control Plane and the workloads it schedules . You'll interact with

A Case Study of Java's Dynamic Proxies (and other Reflection Bits): Selenium's PageFactory

Foreward I spend a lot of time studying the source code of libraries that I really enjoy using. Since my day job is developing automated web UI tests at Red Hat, Selenium is one of those libraries. At the time I started writing this, I was not very familiar with Java’s reflection capabilities, nor what the heck a “Dynamic Proxy” was. The Proxy pattern is particularly powerful, and java.lang.reflect ’s dynamic proxies provide a fairly nice way to do it. Dissecting PageFactory demonstrates. Foreward What is PageFactory? Charlie and the Page Factory A Factory in Chicago that Makes Miniature Models… of Factories 1. Instance an ElementLocatorFactory by giving it a SearchContext 2. Instance a FieldDecorator by giving it the ElementLocatorFactory 3. Use the FieldDecorator to assign references to the page object’s WebElement fields Summary What is PageFactory? Selenium WebDriver comes with a fancy class called PageFactory . It allows you to write your page object’s lik