Testing Concept

Introduction

To ensure the functionality of our project, we make use of automated tests in our Continuous Integration (CI) pipeline. This allows us to have feedback on whether newly implemented and old functionalities are operating correctly.
It's also important that this feedback is fast to not delay our operations. That is why, a good balance between unit tests and integration tests has to be struck.
For that, we refer to the Martin Fowler article that presents the fundamentals on creating a good testing pyramid. In a testing pyramid, tests that require more CPU time are at the top of the pyramid and are few. The opposite happens the lower you go in the pyramid.

This is the testing pyramid for the SecureCodeBox:

We have unit tests for the different SCB modules (e.g. Operator, Hook, Scanner ...). These tests are meant to be fast. For our integration test, we run a complete SCB scan in a Kind Cluster and we evaluate the resulted findings. The following articles describe how each module implements its unit and integration tests:

• Operator
• Scanner
• Hook

We use Make as a basis for our testing framework. The Makefiles expect additional software to be installed:
git, node + npm, docker, kind, kubectl, helm and yq.