Missing Feature and step definition files

I recently realised that there are tests that lack feature files corresponding step definitions in the qa framework . However these tests are covered in legacy selenium

Could it be worth it to write them up .

Some of them are below

And a few more others

@christine @kdaud @sharif

1 Like

Thanks @insookwa for the catch , this is something we wanted to touch to it as well after we had worked on a number of tests, We need to have them in jira as tickets and let them open to be fixed

Oh thanks @sharif i want to be working on a few of them these days how can i go ahead if its okay

Thats awesome, let me create those tickets in jira and probably you can start work on them, However lets wait for jira to be up probably by tomorrow

1 Like

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!

cc: @ibacher @dkayiwa @christine @jennifer @sharif @grace

1 Like

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.

@dkayiwa @ibacher @christine any advise on this epic?

1 Like

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

Shared a pull request someone can dive into https://issues.openmrs.org/browse/RATEST-171 bravo @insookwa

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?

1 Like

Thanks @grace , i think Every point is clear , Thanks for clarifying especially on handling steps definition classes :slightly_smiling_face:

1 Like