Interop tests

[tardyp]

In my experience with AI assisted spec-driven development, AI lie about its success to achieve prompted goal.
Some functions are marked implementing a requirement but they are not. AI reviewers assume the requirement is implemented when its not. Requirement is unclear about a subtlety and they both conclude its fine.

With all due respect for your great work, I see here a risk of test and code "inbreeding", both built from the same spec maybe sharing the same misinterpretation.

interop tests are imho a good way to find where the lies are located.

vsome/ip is the industry standard opensource implementation of some/ip

# Interoperability Testing (requires vsomeip3 and Boost - off by default)
if(BUILD_VSOMEIP_INTEROP)
    add_subdirectory(vsomeip_interop)
endif()

Well, there is no such vsomeip_interop directory :)

With code now being so cheap, it is easy to build a stack perfectly suited for your needs.
Then the value of opensource is in the interop test suite.

[vtz]

Thanks for raising this @tardyp — you're absolutely right.

We had started work on vsomeip interoperability tests earlier but the effort was abandoned before completion. Unfortunately only partial scaffolding landed in main — the BUILD_VSOMEIP_INTEROP CMake option, the add_subdirectory(vsomeip_interop) call, and some doc references — while the actual vsomeip_interop/ directory was never committed. This was not properly reverted at the time, leaving a broken build path and misleading claims in the documentation.

I've opened #236 to clean this up: removing the stale CMake option, the dangling add_subdirectory call, the pointer in the protocol_checker README, and correcting the false "interoperability testing passed" claims in our test docs.

Your broader point about test/code "inbreeding" when both are built from the same spec is well taken. Cross-stack interop testing is the right way to surface misinterpretations, and it's now properly tracked as a gap rather than falsely claimed as done.