

Ask HN: How best to build a Python-based integration test suite? - josh-wrale

I&#x27;m working on a project where I need to do integration testing against a stateless REST API that is written in Java.  The API tier itself is stateless, but there are several stateful APIs and databases behind the API in question.<p>The team has an existing test suite of around 20 test cases that consists of Python scripts backed by a sort of QA-Team-produced SDK module for that API.  All test cases are at present performed manually.<p>My first assignment is to write a shell script that manually runs all the test cases (Python scripts) and displays friendly results while handling the shuttling of logs around the filesystem (all test cases write to the same log file in .&#x2F;).<p>In the long run, I think Jenkins would be a good way to seat the scripts and their results in a web-enabled dashboard&#x2F;HUD.  Also, I wonder if using a Python testing framework would resolve the need to maintain (NIH-style) all the scaffolding.  Would mock backends make sense here?<p>I&#x27;m eager to forge, once I gain a better understanding on the systems and existing testing methods, a more automated and efficient QA pipeline.  Any tips would be very helpful and much appreciated.<p>Thanks!
======
viraptor
> a shell script that manually runs all the test cases

There's likely a better and faster way of just doing that in Python. No need
to read the list and try to parse it properly in shell.

> Jenkins would be a good way to seat the scripts and their results

Yes, likely.

> if using a Python testing framework would resolve the need to maintain (NIH-
> style) all the scaffolding

Depends what's in the scaffolding and what do you log. Unittest framework will
help you with test discovery, running and collecting results. It will not make
application-specific logs easier. It may actually make it harder if by "log"
you mean just printing to stdout/err.

> Would mock backends make sense here?

This doesn't really follow from previous text. You're either using mocking
concept in your tests or not. If they're used and implemented locally, there
are probably good reasons to move to known mocking modules. If you don't use
mocking, that's a question completely different from the execution framework
itself.

