ENGYAK.co Logo
ENGYAK.co

Why Automate Writing a self-testing Python class for REST or XML API invocation

 So far, most API invocations, at least in terms of what you need to do, are pretty simple to execute.

Then again, just about every other administrative function on a computer is, as well. For example:

Interacting with a programmable interface is as simple as any other interaction with a computer.

The primary goal with an API is not to simply replace any of those functions normally performed by a user. Using a programmable interface effectively skips most of the rigmarole performed by a skilled administrator, like:

As an example, when you enter a vehicle to back it out of a driveway, you achieve these goals:

While most people don’t always fully realize that they’re performing these steps, each is typically present. We see many instances in the industry where engineers are considered “unreliable”. In my experience, these individuals just aren’t aware of those steps, and simply need to make it a conscious effort.

This has to be a fully conscious effort when developing software or automating changes. While a programmable interface does not perform these things automatically, we can do them ourselves relatively easily, given the right tools.

Let’s cover this in micro first - and cover the concept of unit testing.

Unit testing is based upon the principle, that, for every individual thing you can do programmatically, you should at least test once.

The website Software Testing Fundamentals actually covers unit testing itself much more thoroughly than I will here, as this is geared more towards immediate practical applications for people who don’t exclusively write code for a living.

This is step one to ensuring that programmatic changes are correct, appropriate, and won’t have unintended side effects or at least ensuring your infrastructure won’t end up on r/softwaregore

For this to work, every single software function executed must be proven just like any other mathematical formula. Typically, the easiest way to do this from a pure mathematics standpoint is by trying the formula in reverse.

I’ll be honest, this doesn’t scale particularly well when dealing with infrastructure programmability. We used to joke in college that physicists and mathematicians would start with “assuming a cow is a sphere at absolute zero in a vacuum,” but we didn’t really understand that yet. The joke was probably inherited and re-used, where:

We, as engineers designing infrastructure, have limited time and resources to tackle the fractal complexity of what we consider the “real-world.”

Infrastructure designers and maintainers live somewhere between the two, where software is based on mathematics but is slowly approaching the fractal complexity of the “real world.”

So, we rip off what other engineering disciplines have done for millennia, component testing.

Typically, engineers test a component based on results, or by breaking a component. Some examples of where these approaches are practical are:

Third-party tools like pipelines can cover automated test EXECUTION, but before we cover that, we need to cover how to test, and better yet, how to bake testing in so that it doesn’t take much effort.

If you already have a library that you’re re-using to execute changes, you’re handing off responsibility for mathematical proofs, but as the person executing a change, you still have operational responsibility for any unintended effects. So you treat this as an engineer, and move forward with simulations and fuzzing.

Let’s start by creating a Python class. PEP 8 - the style guide for writing python code, has a lot to say about names. I’ll call this one IronStrataReliquary, for the following reasons:

From here, we structure the class by illustrating a rough outline for what the class should contain:

All I have to do, once done, is write an exceedingly simple script to test this out:

Logic Loop

Since the array in question already stored expected responses, I’m able to apply a for loop and just iterate through all of the provided XML Queries and responses to test the code with nearly full coverage. After I’ve finished the rest of the PEP 8 / Code conformance, the last remaining work is to: