Proof of concept for implementing frontend integration tests

The frontend testing guide mentions frontend integration tests as a testing level between unit tests and system tests (spec/features/).

In Karma the distinction between frontend integration tests and unit tests is not clear and we have not framework that supports the former. Additionally we are aiming at migrating all Karma tests to Jest (&895 (closed)).

In Jest we are currently running all tests in JSDOM and not in a browser. This implies that certain scenarios cannot be tested or behave differently than in the real application. Additionally Jest does not provide a framework for integration level tests either.

This issue is meant to evaluate our options by implementing a proof of concept for frontend integration tests.

Old description

Support running Jest tests in browsers

Our Jest tests currently run with jsdom which is the default. We should look into ways to also make it run in real browsers.

See also

• https://github.com/smooth-code/jest-puppeteer
• https://github.com/GoogleChrome/puppeteer/tree/master/experimental/puppeteer-firefox/

This issues is meant to provide a proof of concept. We can then create follow-up issues for the implementation if necessary.

added Quality frontend test labels

mentioned in issue #52483 (closed)

added to epic &873 (closed)

mentioned in issue #59975 (closed)

marked this issue as related to #59975 (closed)

@donaldcook Should we make this a proof of concept issue and add it to %11.11?

Sorry for the delay in response @winh. Yes, let's just treat it as a spike (proof of concept) in %11.11

changed the description

changed milestone to %11.11

added [deprecated] Accepting merge requests label

/cc @arthanzel

@donaldcook I missed this because I forgot to add the ~Plan label, so it didn't show up in our issue board. I will move it to %12.0 if you don't mind.

changed milestone to %12.0

added Plan [DEPRECATED] label

mentioned in merge request !28317 (merged)

added backstage [DEPRECATED] label and removed Quality label

changed weight to 1

Weighted as 1 for the POC. Update if you think it should be different @winh @arthanzel

changed milestone to %12.1

changed milestone to %12.2

added devopsplan label

mentioned in issue #49799 (moved)

changed milestone to %12.3

Given that my current task (https://gitlab.com/gitlab-org/gitlab-ee/issues/9475) needs some clarification, I'm going to start on this.

assigned to @winh

removed [deprecated] Accepting merge requests label

I looked into running the existing Jest tests in a browser using jest-puppeteer following the official guide. As part of this I realized that we are remote controlling a browser (as the name puppeteer suggests) but not running our code in the browser environment. That means we would still test our units / components in a node.js environment and only use the DOM of a browser. To me this defeats the original intention behind this issue.

However I'd like to rescope this issue based on conversations I had with @pslaughter and @dennis:

Given that the overall goal is to test the integration of our frontend code with a browser environment, we should run these type of tests at the integration level separately from the unit testing level. That is: Unit tests will continue to run with Jest in JSDOM (spec/frontend/) and we will create a separate environment for running frontend integration tests in a browser environment (spec/frontend-integration/ ?). I will update the frontend testing guide to make this more clear (currently blocked by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31852).

I have scheduled a call with @wlsf82 to discuss whether it makes more sense to leverage Jest for the integration tests (which does not ship with such a concept) or if we get more benefit from a tool like Cypress. Cypress in particular only runs in Chrome and Electron so far.

Since you are thinking about using Cypress, I have already experimented with it for some end-to-end tests on GitLab, and it works pretty well. See https://gitlab.com/wlsf82/gitlab-cypress.

@winh, as I have mentioned during our Zoom call, in this issue, I list some pros and cons of Cypress. I hope it helps you in deciding on using it or not.

changed title from Support running Jest tests in browsers to Proof of concept for implementing frontend integration tests

changed the description

I have updated the issue title and description to reflect the new scope.

I'm unassigning myself for now to prioritize https://gitlab.com/gitlab-org/gitlab-ce/issues/61468. After that one is finished, I intend to continue here.

/cc @donaldcook

added workflowready for development label

unassigned @winh

added [deprecated] Accepting merge requests label

changed epic to &184

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

mentioned in merge request gitlab!16567 (merged)