Granta MI Python STK Unit Tests

Clay Records

What is the best way to create unit tests for scripts using the MI Python STK, without accessing external databases?

Unit tests should be able to run without a live connection to a database required, and shouldn't rely on a database's state to pass. But if a script makes extensive use of the MI STK then it is challenging to get started with unit tests. Mocking MI objects is not easy, since so many of them cannot be directly instantiated, have properties that make database calls, or are simply too complex to recreate. This results in more time making mocks of the STK than actually testing the script.

The best way I have found to add unit tests to complex scripts is to use the STK only where required. For example, instead of a function accepting a granta.Record instance as an argument, it could accept a record identity and a dictionary of attribute names to attribute values. Or I can create my own custom.Record class that contains all the relevant information, and convert it to/from a granta.Record where needed.

However, this feels like circumnavigating the well-designed Streamlined STK and recreating objects unnecessarily, potentially introducing errors. For an ETL script, it would be easier to keep the same record objects throughout the transform.

Is there an easy way to create unit tests for sufficiently complex MI scripts? Is there a good way to mock MI objects?

Thanks!

Andy_Grigg

To answer your question at face value, I'd say unittest.mock.Mock or variants thereof. There are no better-mockable low-level interfaces, so mocking the public objects is the only option. Improving the mockability is something we could look to develop and ship as a feature, but this would be a significant amount of effort and has to be weighed up against adding other features and fixing issues.

More generally though, your question touches on the recommended way of including Scripting Toolkit in a codebase. This typically depends on both the complexity and expected longevity of that project, because that's going to have an impact on how testable and maintainable the code needs to be. If you've got a single-use script, it doesn't matter how complicated it is, you'll probably manage the Scripting Toolkit objects directly, and testing will just be a case of running it and checking it did the right thing.

On the other end of the spectrum is an application that is expected to be run and maintained for multiple years. Within that time Scripting Toolkit will be updated and modified, likely with new features coming in and maybe old features being deprecated and potentially removed. In this world, you probably want a layer between your app and Scripting Toolkit which wraps the Scripting Toolkit objects.

You'll probably apply the dependency inversion principle such that both the Scripting Toolkit abstraction and your app depends on some interface, leaving you free to modify the Scripting Toolkit part of the codebase while leaving the rest of the app unchanged. You'd have the following components:

1. Non-Granta parts of the app (A)
2. Custom Scripting Toolkit interface (B)
3. Scripting Toolkit (C )

Hopefully B will be very thin, and indeed the thinner B is the better, because it means Scripting Toolkit has a very usable interface. I think it's still useful to keep though, even if it's just a whole load of proxy classes which do nothing except wrap the Scripting Toolkit object.

You can then test the following:

1. A makes the right calls to B (unit tests)
2. B makes the right calls to C (probably require calls to Granta MI, but hopefully there are a minimal number of 'unique' test cases that are worth running)
3. A, B, and C together (integration tests)

Ultimately though, it's a spectrum, and so the right approach for a given situation is probably somewhere between those two. Additionally, as I said at the top, it is in principle possible for us to create a way of running Scripting Toolkit itself that doesn't require an instance of MI and could be used for isolated testing. At best though this is a long way into the future and is not currently planned.