OCPP 1.6j Security extension tests

[xBlaz3kx]

Proposed changes

• Added OCPP 1.6 Security extension tests
• Added a CI pipeline for autogenerating mocks

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of
them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before
merging your code.

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Further comments

[xBlaz3kx]

@lorenzodonini Would you mind reviewing this when you have some time? I would like to get this merged, as currently there are no tests for the security extension

[lorenzodonini]

Thanks for adding the tests! I'm a big fan of not committing auto-generated files and rather generate them on-the-fly (it just needs to be documented in the README). Any specific reason you prefer checking them in?

[xBlaz3kx]

Thanks for adding the tests! I'm a big fan of not committing auto-generated files and rather generate them on-the-fly (it just needs to be documented in the README). Any specific reason you prefer checking them in?

No particular reason, I'll set up a pipeline for that.

Edit: Come to think of it, I think I might have misunderstood the whole sentence.

Basically, instead of manually writing mocks like in ocpp1.6_test and ocpp2.0.1_test packages (because I'm too lazy to do it manually and the mock generation is standardized, so we dont need to argue about the structure), I prefer to generate mocks, plus there are a couple of assertion benefits that come with mockery generator.

Since tests are based on generated mocks and mocks are generated from interfaces (which can change), they should be included in the commit. The tests will fail anyway if mocks arent up to date.

[xBlaz3kx]

@lorenzodonini I've managed to create a CI pipeline for autogenerating mocks.

One known issue with the pipeline currently is failure at commit files step because of the refs:
The pipeline running on this repository seems to sync with my forked repository's branch, but fails to check out my fork's branch to run the autogen on.

Another potential could be adding newly generated files to VCS from the workflow. For some reason, the GH action format validation fails if I try to pass inputs to stefanzweifel/git-auto-commit-action@v5 (which according to action docs, should work), so I cannot tinker with any git commands.

It should be good enough for an initial version, and I'll try to fix these issues asap.