If I could have it run at the end of a suite that would be best as then I could fix the problem of potentially re-uploading old results, but I’m not sure how to do that without having to build a katalon plugin… in the future I can build a plugin, but since it requires Java I’ll have to rewrite the code as I wouldn’t be able to use the libraries for azure devops. It’s doable, though.
there is a small problem with this approach.
the app wrote by @jeanie.conner is parsing the JUnit_Report.xml file … which I don’t think it is available yet at the ‘AfterTestSuite’ stage. I have the feeling it is created after the testsuite scope is totally completed (not sure on this, I have to check)
So, a different approach may be needed. I think the data about executed testcases it is available in the testsuite context at this point … (again not sure,need to explore)
Another approach may be to use @AfterTestCase listener and update the results on the fly (status can be retrieved from testcase context) but for this the app code has to be re-implemented in katalon, e.g in a certain keyword (there is no need for a plugin)
In the end are just API calls so shouldn’t be very difficult.
duh - I think you’re right. I seem to recall that biting me a few years ago – and one of the (many) reasons I decided to write my own reports.
Sorry Jeanie, didn’t mean to lead you on a fool’s errand.
There’s probably something you can do with a file watcher (maybe via groovyshell?) but not something I’ve tinkered with in groovy/java or even C#. If @bionel is correct (pretty sure he is) , a file watcher would be the way to go.
thanks for all the info @Russ_Thomas and @bionel - I’ll still look into how I can integrate it via keyword and the test listener without relying on the reports being generated, as that might be the most seamless way to do it. I think I’ll have to rewrite to call the rest API instead of using the client libraries to integrate with azure devops, but we’ll see.
Thanks again, will update later!