Improve incomingDiagConnection interfacing

[guillaumeaub-ctw]

No description provided.

[christian-schilling]

I'm currently working on a big refactoring of UDS and as part of that refactoring aim to remove the use of interfaces, virtual and mocks as much as possible. This change is in direct conflict with those goals.
What is the underlying need/problem you are trying to address? I'm sure we can find a better solution.

[guillaumeaub-ctw]

Hi @christian-schilling,

The goal of this POC is to make JOB implementation and later UDS independent of transport. At least the parts that users need to integrate.

Here is our problem :

• UDS is globally not dissociated from transport library which is hardware dependent.
• When an openBSW user is integrating new jobs, he would like to unit test them in an isolated environment.
  Actually it is not possible because IncomingDiagConnection is depending on transport depending on hardware related libraries.

So, I was trying to see how we could decouple a maximum Uds from transport by introducing an interface that could be mocked. Using that PR we could limit the dependencies of our jobs uts to :

• etl
• uds config : libs/bsw/uds/test/mock/include/uds/
• async : libs/bsw/async/mock/gmock/src/async/
• We still had to create a manual mock for transport as the PR is not finished

How could we unit test our code if you remove mocks and interfaces ?

[christian-schilling]

Thanks @guillaumeaub-ctw for the clarification.
So the problem is not really IncomingDiagConnection or the dependency on UDS itself, but rather the fact that it drags transport and lower level dependencies with it.
So the solution I have in mind it breaking up the IncomingDiagConnection class entirely into smaller parts so that for job testing only the relevant parts need to be used.

[guillaumeaub-ctw]

Good morning @christian-schilling,

Do you have a PR I can look at so I can see the direction it will take and how we should adapt ?