I think it’s a positive step, but it still masks the underlying issue. I have been fighting with trying to import an older test plan for probably a week now, with no good resolution in sight. I have even tried to go back to a previous version of OpenTap (although maybe not far enough). I am very concerned about future portability. The whole serialization/deserialization thing seems very fragile. I would much prefer to see some type of alias or dictionary used which would insulate the plan from internal code changes (in fact, the test plan importer should probably be its own plugin). With regard to using an alias, maybe something simplified based on just the root function name (ignoring serialized path) and just the Major/Minor rev (ignoring build, etc…by standard versioning practices these changes should be backward compatible anyway). Even if something broke with this scheme I think it would still end up being way easier to hack the test plan file and fix the problem. Right now I’m having to rebuild my 100+ step test plan from scratch, and that is no better of a solution.
2 Likes
I guess though I’m off-topic for the original thread. If the issue is just with a missing plug-in which someone just needs to open the PackageManager and install then this fix seems suitable enough. But from my experience the issue was not that the plug-in was “missing” per se, it was that the importer was not able to resolve the different path to the plugin because it was moved/renamed, which then messed with the links to the various test steps. So same end symptom, but a different root cause.
2 Likes