IocTestFramework: Generalise to work for CLF

[DominicOram]

As a developer in CLF I would like to make use of the IOCTestFramework to test my IOCs. Some changes that need to be made to use it:

• CLF use Linux, the IOCTestFramework needs to work for both Linux/Windows
• The IOCTestFramework currently uses genie_python for channel access, solutions to this are:
  1. Make it optionally load genie_python or some other channel access library
  2. Remove genie_python entirely and just use a different channel access library
  3. Make genie_python public
• Make it configurable where to start IOCs from

@chris-d-gregory is happy to do this work

[DominicOram]

@chris-d-gregory is there anything I've missed from that list?

[DominicOram]

I think I prefer option ii but open to others thoughts

[rerpha]

They are system tests at the end of the day, so should work over anything that can do channel access. Can we use https://nsls-ii.github.io/caproto/ like the forwarder?

[DominicOram]

Haha, that's the exact library CLF were proposing. I can see the argument that they're also testing genie_python for us to some extent but I dislike having the tests coupled like that, we should be testing genie_python separately

[rerpha]

yup I agree. option ii is the best in my eyes. I guess a fourth option would be to write a wrapper, so the ioc test framework is modular? that way we could use either/both. means we could use the same interface we're currently using.

[JackEAllen]

Is there any special need to stay with genie_python to justify a wrapper?

[rerpha]

Is there any special need to stay with genie_python to justify a wrapper?

Not that I can think of, but other group members may disagree

[DominicOram]

I think that's what I meant by option i. There's an argument there that it's good design practice to isolate it in a wrapper anyway so that we can swap to some other channel access library easily in the future if we had to. Maybe the best solution is to do ii but in a way that abstracts things so that we could go back to using genie_python if we want to

[chris-d-gregory]

Thanks @DominicOram - that covers everything that I can think of at the moment, but we haven't done much investigation yet. I did have a look about 6 months ago, and got it to run a single, simple test under linux with only minor changes. I used caproto to re-implement just enough of CaChannelWrapper and UnableToConnectToPVException to get my test to work.

[FreddieAkeroyd]

Keeping a wrapper also lets us test epics v4 to an ioc with p4p for example

[FreddieAkeroyd]

@chris-d-gregory a user on epics tech-talk would be interested in your CaChannelWrapper and UnableToConnectToPVException implementations

[chris-d-gregory]

Hi @FreddieAkeroyd - yes, just saw your post. It's not complete, just the minimum needed to get a simple test to work for me. It's a start though. I currently have it sitting in a clf-development branch on a fork of the ISIS EPICS-IOC_Test_Framework repo.

If this might have wider interest, would it make for someone in ISIS to make a branch off your repo for this work and I'll tidy up what I have and submit a PR?

[DominicOram]

I've created a PR for merging your work in @chris-d-gregory, I think just carry on pushing any tidying up you want to that branch and let us know when you're happy for us to review.