Discuss: How can we do better to maintain test coverage of features being migrated to Vue/GraphQL
There is more and more functionality in GitLab that gets migrated to Vue. Also, a lot of Vue parts of the application start working with GraphQL as the API layer. But the problem is that current feature tests set up and established patterns not always work optimally with these new trends.
The following discussion from !28600 (merged) should be addressed:
-
@tmslvnkc started a discussion: (+4 comments) @dmishunov Why are we disabling the
vue
feature and thus not testing the newvue setup
in our feature tests? That seems counterproductive as thevue view
should be replacing the old one? Not sure if I am misunderstanding something🤔 If the tests are not compatible with the new view, wouldn't a rewrite / refactoring of the tests be more appropriate?
Relevant Slack discussion:
-
On https://gitlab.slack.com/archives/C3JJET4Q6/p1587112472367100:
After a discussion with @dmishunov that started here, it seems that we are building debt inside the spec/features folder…
-
On https://gitlab.slack.com/archives/C0GQHHPGW/p1586983930486200:
Those who had been doing refactoring of large HAML parts to Vue: what did you do with the RSpec tests? In particular, if the refactoring happened behind a feature flag. Did you update the specs? Did you disable the refactoring feature flag for the specs and left those to run against HAML app? Anything else?
-
On https://gitlab.slack.com/archives/C02PF508L/p1587061281443800 concerning the
wait_for_requests
and its lack of support for GraphQL mutations and queries