Good day. I remember that in one series about memorizing, the guys drove a stereo system, located within the reach of their own hands, from a computer, transmitting a signal via the Internet across the entire planet. The sensible girl whom they wanted to surprise was not impressed, for she believed that the usual remote control was cheaper and simpler.
Nevertheless, there is good news: an incredible machine can still be useful. For example, for testing software systems. While working on a large ERP-system OpenPapyrus , which, among other things, should be able to display barcode images of different standards and properties, we have connected the popular zint library for barcode rendering. The library was integrated and earned. But you still need to test the result.
The most suitable option for the test will be testing through the inverse function: ')
random data are input, converted by the function then the function is applied to the result back to and compares the output with the original data. Two functions are tested at once with an armor-piercing proof of correctness of work (not, of course, algorithms, but implementations).
The inverse function to the rendering of the barcode will obviously be the recognition of the barcode image. No sooner said than done. We took another open source library zbar . Integrated - earned.
Now the testing scheme has become quite clear: the input data is a textual representation of the barcode and its standard (ean-13, ean-8, upc-a, code-39, qr, etc.). This representation is converted into an image, which is immediately recognized and as a result we get, again, a textual representation and a standard.
Thus, we tested the following components:
Zint library
Libpng library (when outputting and recognizing code in png format)
Zlib library (it is used by libpng and many other subsystems)
The libjpeg library (when outputting and recognizing code in jpeg format)
Zbar library
Own infrastructure that integrates and connects all this
We have one more step left: zint can display a barcode in vector format svg, however, zbar does not understand this format with its own means, but we have our own infrastructure for reading and rendering svg-images. Add another nodule to our scheme and include it in the test. Everything is working.
Now we can add to the list of tested components:
Module for reading svg-files and converting them into internal vector format
Vector Image Rendering Module
Brief total
The described test is remarkable in that it uses a significant number of modules for various purposes, implemented independently of each other. Another of its valuable properties is the conversion of data between qualitatively different forms (text - vector image - bitmap - text).
And a fly in the ointment: such a test, having excellent demonstrativeness, is not sufficient. It verifies the functionality of components in a very narrow range of areas of definition for each of them. That is, it is impossible to count on the completeness of testing using the “incredible machine” method (interestingly, has anyone used this term in such a context before?). Detailed tests of individual functions, it does not cancel.