Hot Fixture Tool

Legacy code is still a problem (?)¶

Today code is written with ORM and well designed, but what about legacy code?

Legacy code is hard to change.

Legacy code is difficult to maintain.

Legacy code is going to die.

What does it care: input -> output¶

The easiest way to deal with legacy code is to treat it as a black box, with an input and an output.

Then change and test:

• input
• output vs expected output

If the output != expected-output, then the change is not accepted.

Define a test by wrapping the legacy-code.¶

If input and output are both stream, defining the test is easy.

But when input is compound of command-line, data in db, data in filesystem, and also the expected output is compound of stdout, db data, and filesystem, to define a test case becomes an hard task.

To automate the test, the general direction is:

• define a fixture on db, filesystem, command-line input
• commit that fixture
• run a supporting code, that execute the real code
• run a supporting code that test if the expected-output is fulfilled.

The supporting code wraps:

• the fixture commit
• the legacy-code execution
• the expected tests

Since most of the time the legacy code does not conform to best practices, the use-cases is a big domain, resulting from a cartesian product of input X db-data X filesystem state.

This means that number of starting fixtures to start from is too big to be considered all.

Anyway, you have to start from somewhere, from something real.

Hot fixture tool¶

Hot-fixture-tool supports the download from real data (hot data) from real environment, to the testing platform or CI tool. The data-fixture is both db and filesystem storage.

This is done by:

• hftd: a service running on remote host. (it is a docker image, or a simple https server)
• hfit: a client utility that talk with hfitd to inspect data, and to download package
• One or more package definition files, that enable to prepare an export of existing data, to the development environment.

Also,