[e2e] Discussion being tested three times

[tuliobluz]

Is your feature request related to a problem? Please describe.

The discussion functionality is shared by HowTo, Question, and Research, with that, there are e2e to all those 3 features. So, the same functionality is being tested three times. I did not see any big difference among the assertions.

Describe the solution you'd like

The solution is the discussion functionality should be covered by only one spec e2e. Then, we avoid duplicated code, reduce the e2e total run time, and it would be easy to maintain.

You can also check if the discussion is displayed on the other pages.

Describe alternatives you've considered

If it is indispensable to test discussion for the 3 pages, we can do a refactor creating commandsUi to be shared among the 3 specs files. Then, we avoid duplicated code and it would be easy to maintain.

[benfurber]

While the user action is currently identical across the three document types, the following is different:

• the templating with business logic
• the side effects through the discussion store
• some outputs have their own independent business logic

(This is especially true of research compared to the other two.) So without the seperate specs, it would be very easy to create regressions.

I agree the code is repeative though, so I like the idea of a command ui or two.

[mariojsnunes]

• the templating with business logic
• the side effects through the discussion store
• some outputs have their own independent business logic

Would it be possible to reduce/eliminate those differences?

[tuliobluz]

Another alternative to cover the Business is using API testing via Cypress.

I was trying to go over the code, but I am not 100% sure, those are the parts that have differences, and Research is the one where most distinguished from HowTo and Question.

• discussion.events.tsx
• discussions.store.tsx

Approach:

• One spec covering the UI functionalities of discussion
• Two new API specs to cover the business.

[benfurber]

Well there isn't currently an API to test. :)

Start with the commandsUi and go from there?

[tuliobluz]

That is true, I forgot about the API.

We have two options:

1. Add all possible steps into commndsUi (Already described comments above)
2. Remove some steps (described below)

Example of Research and Questions to be removed:

• Can create their own comment
• Can edit their own comment
• Can delete their own comment
• Can edit their reply

Then we leave the following steps (Those here we can convert into commandsUi)

• Can add reply
• Can delete their reply'
• Comment generated a notification for primary research author
• Comment generated a notification for update collaborators
• Reply generated a notification for comment parent

And for howTo we leave all the steps to make the full test of the functionality

[benfurber]

Let's go with 1 please.

[benfurber]

There's also some missing coverage on research discussions which meant #3778 slipped through. Should hide the comments after deletion and check the button text has the right comment count.

[tuliobluz]

@benfurber I created a PR for the first solutions and also added assertions to check the comment count.

[tuliobluz]

Closing the issue as it was merged