Coppercomm — One interface to unite them all
How to share test cases across organizations and companies
Background
Have you ever faced the challenge of reusing test cases when testing the same Device Under Test (DUT) across different organizations and companies?
You are not alone. One of the main problems is the different libraries used. And it is not at all unusual for an organization to use different libraries for the same purpose. It could be that one team is not aware of the existence of a library, and decides to create a new one. Suddenly, there are two libraries doing the same thing! It’s like having two different keys to the same lock. The problem grows when there is a need to share the same test cases between different companies and organizations. You might want to run a specific test case before delivering to a customer, and then after the customer has applied some changes, they might want to re-run the same test case again to make sure that it still works. You would want to run the same test case, the same way.
This is where Coppercomm comes into play. It is written in Python and functions as a bridge between the host and DUT, for different types of communication interfaces, like SSH, serial, and Android Debug Bridge (ADB). This enables us to run the same test case at different departments without modifying the test case, as long as the test case is using Coppercomm and the Coppercomm library is available on the host.
How Coppercomm works
Coppercomm is pretty basic. You create a configuration file that maps the different interfaces to a logical or physical interface. The configuration file is then used under the hood by Coppercomm. This hides the mapping from the user, and the test cases only need to specify what type of interface they want to use. Voilà! The host communicates with the DUT, without any specifics in the test case.
Open sourcing Coppercomm
“Given enough eyeballs, all bugs are shallow”
- Linus Torvalds
Sharing the same code for communication between host and DUT has the benefit of many eyes watching the same piece of code. When one developer is solving an issue with Coppercomm, the solution propagates to different organizations and benefits many developers, that don’t have to troubleshoot and fix the same issue.
The idea is that this library can benefit multiple companies as well. Multiple vendors deliver code to Volvo Cars, which is then integrated into a larger product. Having identical test cases, that both the vendor and Volvo Cars can execute, allows us to verify whether the new code was successfully integrated. It will be easier to troubleshoot an issue when the test cases are the same in both ends. To enable that, we decided to open source Coppercomm, so that more people can use it. And in return, that gives us more eyeballs to check for bugs and troubleshoot Coppercomm, sharing their findings through bugfixes.
Have a look at the code here and see if it could be useful for you:
https://github.com/volvo-cars/coppercomm
Conclusion
Creating and sharing a library for testing can save time and effort. It enables developers to share test cases across different organizations, and open sourcing Coppercomm allows it to be shared across companies.
Do you know of more ways to collaborate across organizations and companies? Please comment below for any suggestions.
