Add Cypress and sample basic tests to project

[rileyhgrant]

Add Cypress to the project to be used for e2e testing.

Add sample basic tests that right now only check basic navigation of home page, in home_page.cy.ts

To see tests, open both a local development server and Cypress:

$ yarn start
$ yarn cypress:open

Resolves #941

[rileyhgrant]

Opening as a draft right now, as part of the issue is to evaluate whether we want to be using Cypress - as such this is not to be merged for the moment.

[rileyhgrant]

I think this example is already useful to merge as-is. Would be interested to hear feedback from @ phildarnowsky-broad.

Also, how do we make sure this is run as part of CI/Github Actions?

I did not yet add anything to the existing Github Actions Yaml file to run the Cypress tests, if we do want to use Cypress I was going to read up and get them running as part of our existing CI.

Fortunately their docs are pretty helpful and thorough, and they have a section dedicated to exactly this.

[mattsolo1]

Nice, CI working! This is awesome.

[rileyhgrant]

The gene page basic test now stubs the data, and all GraphQL queries defined in the front end include an operationName field in their body, as is common practice.

[phildarnowsky-broad]

@rileyhgrant it just occurred to me that, if you want to give a talk sometime, a brief introduction to Cypress and E2E testing in general might make a decent topic.

[phildarnowsky-broad]

@rileyhgrant sorry, just noticed one more small thing, another rebase. Specifically, let's take that very last commit Add explicit Jest imports and rebase to fold it into the first commit, where you introduce Cypress.

Then please go through this branch commit by commit (there should be 4 remaining at this point), and verify that the Jest and Cypress tests, as they are in each respective commit, all pass. Probably good to try yarn build in the browser dir as well, even though there shouldn't be any changes that affect that.

Generally, the ideal is for each commit to be clean, meaning that if we choose any arbitrary commit out of the history and check that out in our working copy, we should be able to run all tests and build the whole project, as they exist at that point in time.

As a corollary, I'd suggest that we adopt as SOP the idea that, when you open a PR, and that PR introduces a bug in commit A, which is later fixed in commit B in the same PR, once you feel confident in B, that you rebase in such a way that B gets merged into A, replacing them both with a new clean commit A'.

One trick that can help you rebase with confidence is to make a temporary backup branch. Say you have a git history that looks like this:

123456 did a thing
234567 did second thing
345678 whoops first thing was wrong, fixed here

The desired end state is then:

121212 did a thing (any rumor that I ever did this thing wrong is just a rumor)
232323 did second thing

Now in this case it's simple because you git rebase to move 345678 to directly after 123456, then fixup so they are merged together into the commit we call 121212 here. But if you've got a lot of changes, say after a thorough code review, it can be much trickier, and if you have to resolve conflicts manually you might wonder if you did so correctly.

The trick hinges on this fact: in terms of the actual content, commit 345678 and 232323 should be totally indistinguishable. This means that you can use your pre-rebase version, 345678 here, as a reference to compare the post-rebase version to. You simply do something like:

$ git checkout -b topic_branch_name.BAK1
$ git checkout topic_branch_name

...then make your changes on branch topic_branch_name, and when you're done, just git diff topic_branch_name topic_branch_name.BAK1. If that comes up with anything, you know that you goofed somewhere.

[rileyhgrant]

@rileyhgrant sorry, just noticed one more small thing, another rebase. Specifically, let's take that very last commit ...

Aha, ok very cool. Thanks for this detailed and helpful explanation, particularly my working definition of a clean commit history was faulty (Clean commit history being a commit history that the history itself is clean in a legible and logical way, vs a history of commits that are each individually 'clean' in the way you described above).

This is super helpful, makes a ton of sense, and I'm definitely on board to adopt the principle you mentioned, of rebasing and squashing bug fixes into commits that introduced the bug itself.

Exciting! And thanks for all the guidance, as per usual.

[rileyhgrant]

@rileyhgrant sorry, just noticed one more small thing, another rebase. Specifically, let's take that very last commit ...

@phildarnowsky-broad Alrighty, the history has been modified to keep clean commits and keep relevant code changes in the expected commit.

This also now includes a very minor fix for a @ts-expect-error message that was being printed as text on the Team Page

Thanks for your review and comments.