Milo is a bit painful, but it does more than we currently can do in our
opcua implementation. Also, from basic look I had into why some of tests
fail, it looks primarily like resource lookup issue. For example I
spotted a swallowed null pointer exception which comes from our code,
not Milo.
We will have difficult times making test framework for testing security
with certificates and Java crypto apis. Please hold on with major
changes in this area, as we intend using it to automate testing of UA
security policies (sign, sing&encrypt) using various modes (basic rsa,
basic aes etc.).
Back then Patryk had an idea of making a "test container" for Milo which
would separate it into its own process. Obviously it will need a bit of
work and will become a prerequisite to eventual test refactoring,
however it will make it (fail) same way for everyone. ;)
Best,
Łukasz
On 25.09.2023 10:38, Christofer Dutz wrote:
Hi all,
I know that I have spent many days tracking down oddness of problem with OPC-UA
tests, that all tracked down to Milo behaving oddly on various platforms
(Doesn#t start in Parallells VMs, has issues being run in docker, …).
When building PLC4X I put a lot of effort into our integration-test framework,
which should allow testing our drivers on various platforms and languages
without needing a real (or simulated) device.
I think we should translate the Milo based tests into ones using our
DriverTestsuite framework, as admittedly I’m fedup with Milo …
Chris
