Today I learned about monkey patching. Sounds wired, right? I’ll explain what that means. Talk about some use cases with examples in Go. And align with best practices when using this. Bonus- the funniest software license I have ever seen.
So as the title spoils, the main topic here is testing. Or more specifically- Unit Testing. As good developers, we tend to unit-test our code. Run each function with various inputs and make sure that we get the expected results. However, in a lot of cases, we cannot test all functions easily. some require long initiations for inputs, some rely on an external source, and some require a long prase of known data. There are multiple ways to solve each problem, but although not familiar, monkey patching is a cool and hacky way to easily get things done.
A monkey patch is a way for a program to extend or modify supporting system software locally (affecting only the running instance of the program).
Wikipedia
To use monkey patch in your test, you need to create a function with the same signature: receives the same arguments by type in the same order, and returns the same type(s). behind the scenes, the patching is happening by replacing the pointer value of that function in memory. Then, whenever a call to the function occurs, the patched function will be invoked instead of the original one.
Usage
Seems easy right? True, but like any other developer tool, the hardest part is to know when to use it:
- Usually, you’ll want to replace methods and not standalone functions (because then you can just use the mock one directly…).
- whenever you need to replace an internal function that the function you test MUST invoke.
- When you want to easily mock external service (file, database, network) failures.
When NOT to use:
- When you need to validate your exported data. For example that your database query compiles. In that case you’ll probably want to mock the whole receiver and not a specific function
- in case the service can be easily replaced as a whole
- if you can split the function you want to test into 2 separate functions so you can skip over the external part. probably heard of it as TDD
- IN PRODUCTION.
Bonus
When you look for “monkey patching golang” or any other synonym term you’ll find yourself going to the first result of https://github.com/bouk/monkey.
Then, a big banner with a “read-only” alert shows up. You say to yourself “3K starts, 300+ forks this is probably OK”
You look through the README.md and everything looks fine. so you start using that package. Well, as I learned to look for preferably MIT licenses this one got me by surprise. The most wired license ever:
Copyright Bouke van der Bijl
I do not give anyone permissions to use this tool for any purpose. Don’t use it.
I’m not interested in changing this license. Please don’t ask.
https://github.com/bouk/monkey/blob/master/LICENSE.md
That’s all for today. To be honest, you probably won’t use monkey patching in your next UT, but this is indeed a cool method you will someday need.