Open Source: Testing Software Against a Simulated World for TPCRM

by Mike Duskis

Active participation in open source communities is just one of the many engineering practices at CyberGRX that make me want to get out of bed and write code. It’s a key building block to our third-party cyber risk management (TPCRM )solution that’s modernizing the industry as a whole. This week, we’re kicking it up a notch and committing to share as much of our own work as we can on GitHub.

We’re preparing a handful of projects to release as open source over the next few months. The first out of the gate is an ownership change. A couple of years ago, I built Twin Sister with collaborators at ProtectWise who originally published the project.Since then, I have been developing it actively in-house at CyberGRX so both companies agreed that it made sense to move the repository.

Join The Discussion: CyberGRX Community for Third-Party Cyber Risk Management

Twin Sister solves a problem that crops up frequently when we’re writing tests to prove that the smallest building blocks of our third-party cyber risk management software (“units”) behave as expected.We want to isolate our unit from the rest of the system so we can be sure that our test results are not affected by noise from the outside world. Then, we want to simulate that outside world so we can satisfy ourselves that our unit behaves as it should under tightly controlled conditions. The problem is “how do I accomplish this without violating all sorts of important software engineering principles and making a grand mess?”

The problem is an old one and a number of solutions or partial solutions are available. Simulation turns out to be relatively straightforward. The Python standard library even includes a package (“unittest.mock”) that works just fine for many cases. The tricky part of the problem is tearing our unit out of its natural environment and hooking it up to the simulated one.

Twin Sister approaches this problem with a well-known technique called “dependency injection.” Implementations of this technique tend to be rather violent, hijacking low-level features of language or runtime environment and creating an opportunity for unwanted side-effects. Twin Sister is very gentle by contrast. The injection is entirely voluntary. Each component must opt in or be left alone. The necessary downside of this gentle approach is that the software-under-test needs to know about the dependency injector. It does not, however, need to know whether it is operating under test conditions.

Automated tests play a huge role in our strategy to produce high-quality software (for CyberGRX and industry-wide). We use Twin Sister because we believe it contributes to higher quality tests which then contribute to higher quality software. We welcome others in the open source community to use it as well.

You can see the details and get started with the code at https://github.com/CyberGRX/twin-sister/. If you like what you see, stay tuned. Twin Sister already has a mechanism to simulate the passage of time. Enhancements queued up for the next release include simulating other runtime facilities: environment variables, the filesystem, and Python’s logger.

Interesting technical challenges and the freedom to share solutions barely scratch the surface of what makes CyberGRX such a great place to work. We are truly wiping the slate clean and creating the go-to solution for third-party cyber risk management and having fun while doing it. Find out for yourself – we’re hiring. Or, if you want to force multiply your third-party cyber risk program, we’re always happy to show our tested-and-true solution in real time – schedule a demo today.

MIKE DUSKIS,
TEST MANAGER