We all write code to interface with external systems, like a web service or a message queue. Can you confidently write tests without requiring the system as a dependency? How can you shield users of your code from the inner workings of the interface? Explore one attempt to answer these questions.
There's no shortage of tools at your disposal to solve these problems. This talk will introduce some available options, provide guidance on when one approach may be more appropriate than another, and discuss how to use these tools together to ease the testing process.
This talk will follow one effort to test interactions with an external dependency that evolved over time, as the nature of the interaction became clearer, and as the complexity of the work around the dependency increased.
In the process of testing against the dependency, a variety of tools were used, each of which will be presented with a sample implementation, after which I will discuss their benefits and challenges.
Isolating the interaction with the dependency will be a main takeaway from this exploration. The focus will be the benefits that this provides from a testing perspective, as well as general extensibility towards the overall architecture of your application.
Finally, once the full public API of the system is defined and it's ready to be integrated as part of a larger system or shared with the world as a gem, we will discuss creating a "test mode" for your component. A great example of this is Sidekiq's testing mode. This will cover tips for how to build this functionality, how to expose it to consumers of your component, and the challenges associated with creating and maintaining this feature.
Interfacing with external systems has always been considered a challenging problem. It's also becoming a more common task, as we continue to interconnect with different systems. Microservice architectures make this even more pronounced, as we orchestrate many small, separate systems together to serve as the backbone of our overall technology solution.
Much of my career has been spent identifying, implementing, and maintaining interfaces. My goal is always to make it easy for other developers to interact with the system, and provide them with the information they need to complete their task without needing to be overwhelmed with technical details. I also developed, and continue to maintain, a gem that provides functionality to test interactions with another gem without the need for mocking or stubbing. I've used that experience to inform my choices to ease testing of other interfaces I continue to create. The goal of this talk will be to share how a variety of testing practices can be used in concert when working with external dependencies.
RubyConf 2017 - Waitlisted [Edit]
RailsConf 2019 - Rejected [Edit]
RubyConf 2019 - Rejected [Edit]
RailsConf 2020 - Accepted [Edit]Add submission