We have a build chain. After each code change in our version control (git) there is a build on our continuous integration server. This build creates each time an installable executable and runs some integration tests.
The integration tests will interact with our backend. We have a frontend and a backend. That backend talks to another service, plc’s and other hardware. For the moment there is not yet communication with PLC’s implemented, but it will be soon. For the other hardware, I wrote a hardware simulator in python. I did prefer erlang, but my colleagues objected about it, because the erlang is too difficult. I find that a stupid reason, but not worth arguing about. So I wrote the simulator in python. It was not that hard, because we have some commands that just interrogates some memory in hardware. If a register in memory is set to a value, the real hardware interacts with it. My simulator does not interact with all registers, only with the registers that have state in it.
After I wrote the simulator, I wrote some tests. Integration tests that calls the backend. Why not the frontend? Because it is easier to script calls to the backend, and they are less error prone. At first I choose for the robot framework. This is a keyword driven framework written in python. All tests can be put in version control, so this means that we also can do code reviews and other stuff that the developers do.
I did write the tests in robot framework, but the implementation of the keywords did have an implementation in a library. And now I am happy that I did it this way. Because at a retrospective in the past, we decided that our developers should also write integration tests. The objection was, 2 languages for testing? Can it not be only in python? So I searched a little bit and found py.test. This unit test framework can also run other tests that run longer. It is a nice alternative and the impact to convert from robot to py.test was not that hard. Only the tests itself must be rewritten, because I did implement the driver code already in python. A few sprints later, we had a decent testing framework. And I am also happy, because every team member can now write integration tests, and they are, so I am a happy tester now.