There are things here one needs to understand. Legacy selenium tests were not written in BDD framework which documents user stories within the feature files. As you may see their repo in distro none of them has a feature file and that is the old test workflow. For the past these tests were ignored not run on builds for some technical reasons But now the QA team has resurrected 88% which are already running in master(in the nutshell they are automatically testing their respective uses cases on every ci build and on every merge).
Yes some tests were written in the Legacy selenium framework(old test workflow) however, some use cases for the functionalities were not tested and now we would have them written in the BDD framework(new test workflow).
This showcase explains well the difference between the old test and the new test workflow.
We do not need to write Legacy selenium tests that covered well their respective functionality use cases again in the new test workflow since this will be a waste of efforts. We rather focus on the functionalities that were not covered in the old test workflow and as well those functionalities whose tests(respective legacy test) did not cover some of their use cases.
I would ideally think creating tickets for each of those that qualify in the context and then a contributor can pick any to work around populating the user stories that were not covered for those functionality and as well write its respective workflow in the new approach!
Thanks @kdaud , these feature files need to be written as well, the good thing is, they already have their corresponding pages in distro and some have step definitions classes , so its gona be so easy for them to be implemented quickly
I would think functionalities with tests written in the old test workflow and covered their respective use cases and are running on builds do not need again to be written in the new workflow. This is because they are being tested already on every ci build!
Re-writing them in the new workflow sounds to me a waste of efforts, as mentioned we rather focus on the functionalities that were not covered in the old test workflow and as well those functionalities whose tests(respective legacy test) did not cover some of their use cases.
UseCase: Incase we have already Transfer test (written in old workflow) running in distro master and covered well the use cases of its functionality then I do not see any reason why it should be written in the new workflow again.
It is as if you mean its there is no difference between tests and step definitions, Step definitions work with their corresponding feature files, then tests cannot work with feature files, cucumber wont see them because there is no their corresponding step definition, cucumber can only watch feature files having step definitions following gherkin scenarios by default.
May be your point clears that we cannot write other step definition classes if we already have their written tests classes because this becomes duplicate, i dont know if the point is clear to us , Feel free to throw more light
I completely agree: I don’t think we should be duplicating the old selenium legacy tests by re-doing them in the new QA Framework/Cucumber. Here’s how I thought through this:
Consistency: Yes, one could make an argument that it would be nice to have all our E2E automated tests use the same framework/approach. Especially since gherkin syntax is so easy and clear to interpret what’s going on. But just because it’s nice, do we need this? What would we gain? “Well, it could be easier to maintain the tests, because they’re all similar in structure.” That’s a valid argument. But, would all this effort really be worth it? Over the next year, the main thing we’d gain would not be visible - it would not change whether the tests were seen as passing or failing on the dashboard.
Product Strategy: Let’s step back and ask ourselves, where do we want to invest our time? What’s our major focus area for the OpenMRS EMR that clinicians use? Well, 2.x is not our focus product of the future. So I don’t think it makes sense to re-factor the legacy tests
Exceptions: There might be cases where a step in a new E2E Workflow test is very similar or event duplicates an old legacy selenium test. I would say that in this case it makes sense to kind of duplicate the test as part of the bigger workflow test, but then we should probably raise the specific example to the QA Team together, and propose retiring/archiving the legacy test. Because what’s worse that duplicated effort? Duplicated effort that increases maintenance effort! We wouldn’t want to be in a place where we have an old test and and a new test for something, and then any time it breaks, someone has to fix 2 tests for the same feature.
@sharif what do you think of this? Is there any other key point here you think I might have missed? Can you help me understand any other added value you see?