Skip to content
This repository has been archived by the owner on Sep 19, 2024. It is now read-only.

E2E tests #640

Open
wants to merge 18 commits into
base: development
Choose a base branch
from
Open

E2E tests #640

wants to merge 18 commits into from

Conversation

whilefoo
Copy link
Collaborator

@whilefoo whilefoo commented Aug 20, 2023

Resolves #633

Example of E2E test: ubiquibot-whilefoo-testing/ubiquibot#24

@netlify
Copy link

netlify bot commented Aug 20, 2023

Deploy Preview for ubiquibot-staging ready!

Name Link
🔨 Latest commit 31be5c6
🔍 Latest deploy log https://app.netlify.com/sites/ubiquibot-staging/deploys/6512cf4562ba070008afd03e
😎 Deploy Preview https://deploy-preview-640--ubiquibot-staging.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@gitcoindev
Copy link
Contributor

This is cool. Not mocked but connecting to an actual staging github application using a personal access token and verifying the results. At some point would be useful to add coverage output.

tests/commands.test.ts Outdated Show resolved Hide resolved
@0x4007 0x4007 added ping and removed ping labels Aug 29, 2023
@whilefoo whilefoo marked this pull request as ready for review September 4, 2023 20:13
@rndquu rndquu self-requested a review September 6, 2023 13:14
Copy link
Contributor

@0xcodercrane 0xcodercrane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see @whilefoo you did a lot of works to setup unit tests + e2e.

but I feel like its a little bit away from the original goal.

In terms of unit tests, we should have coverage % in branch and function.
In terms of e2e, need to create a scenario and verify each step -- those need to be in workflow.

src/handlers/payout/post.ts Outdated Show resolved Hide resolved
@0xcodercrane
Copy link
Contributor

0xcodercrane commented Sep 6, 2023

I am gonna contribute to this task as the codeowner because its an very important task for now and future.
No split in payment even if I contribute. The whole amount would get paid to @whilefoo .

To contribute the task(To be honest, I wanna say this is far away from the completion),

  • merge @whilefoo 's branch to feat/e2e
  • I will push my work on feat/e2e. @whilefoo you can continue working on feat/e2e branch cause you're already a member. right?

What do you think @pavlovcik @rndquu @whilefoo ? If you agree about my contribution plan, please react with 👍 .

rndquu
rndquu previously approved these changes Sep 6, 2023
Copy link
Member

@rndquu rndquu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clear the terminology, by "e2e testing" we mean running tests against a staging organization in a real github environment.

The original issue states the test script should file a new issue on a locally configurable repository (.env) that tests all the bot commands. Covering all cases is a huge task so this PR tries to cover at least some cases.

I actually have hard time running the tests getting thrown: "Exceeded timeout of 10000 ms for a hook error all the time:

  commmands test
    ✕ /wallet correct address (5 ms)
    ✕ /wallet wrong address
    ✕ /multiplier
    ✕ /query
    ✕ /query wrong username
    ✕ /help
    ✕ /allow
    ✕ /start and /stop

  ● commmands test › /wallet correct address

    thrown: "Exceeded timeout of 10000 ms for a hook.
    Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."

      150 |   let issue: Issue;
      151 |
    > 152 |   beforeAll(async () => {
          |   ^
      153 |     const res = await octokitAdmin.rest.issues.create({
      154 |       repo,
      155 |       owner,

      at beforeAll (../tests/commands.test.ts:152:3)
      at Object.<anonymous> (../tests/commands.test.ts:149:9)

Nevertheless I think that the current PR is good to merge and we should run e2e tests introduced in the current PR in a github CI ASAP because every new feature makes the e2e tests implemented in the current PR a bit obsolete.

I would:

  1. Merge the current PR
  2. Add a new CI workflow that runs e2e tests in a staging org on every push to a newly created PR by a bounty hunter (+fix the timeout errors)
  3. Create a new issue to refactor e2e tests step by step to cover all basic cases (i.e. commands)
  4. Start implementing unit tests (which is a totally different epic)

P.S. E2E tests on a staging org are gonna be really brittle but it is better than nothing

@0xcodercrane
Copy link
Contributor

0xcodercrane commented Sep 6, 2023

If the task is a minimal goal of overall E2E, we can merge the PR. but we should add yarn test to workflow file on the current PR @whilefoo.
So we can quickly review the hunters don't break the commands in review step.

From @rndquu 's comment,
2 should be done before 1.
For 3/4, we already have an epic so we can create subtasks from it.

@rndquu
Copy link
Member

rndquu commented Sep 6, 2023

If the task is a minimal goal of overall E2E, we can merge the PR. but we should add yarn test to workflow file on the current PR @whilefoo. So we can quickly review the hunters don't break the commands in review step.

From @rndquu 's comment, 2 should be done before 1. For 3/4, we already have an epic so we can create subtasks from it.

So we keep the current e2e tests and add a new "test workflow" as a part of the current issue, right?

@0xcodercrane
Copy link
Contributor

So we keep the current e2e tests and add a new "test workflow" as a part of the current issue, right?

Right. In that way, we can make the PR valuable after the merge.

@whilefoo
Copy link
Collaborator Author

whilefoo commented Sep 6, 2023

I got rate limited one time during development, so I'm worried if we enable this for every commit, we will get rate limited quickly.

@0x4007
Copy link
Member

0x4007 commented Sep 6, 2023

I got rate limited one time during development, so I'm worried if we enable this for every commit, we will get rate limited quickly.

Different GitHub CI events to consider, including only running on merge to development if rate limiting is a concern.

@rndquu
Copy link
Member

rndquu commented Sep 6, 2023

I got rate limited one time during development, so I'm worried if we enable this for every commit, we will get rate limited quickly.

Yes, perhaps we could run e2e tests only on push to the development branch

@0xcodercrane
Copy link
Contributor

I got rate limited one time during development, so I'm worried if we enable this for every commit, we will get rate limited quickly.

Yes, perhaps we could run e2e tests only on push to the development branch

The problem I am seeing if we enable e2e on push event in the development branch is that we (as a reviewer) couldn't verify the hunters don't break before merging the PR right?

Even if we have rate limit, we should allow e2e tests on every pull requests to development branch.

@rndquu
Copy link
Member

rndquu commented Sep 12, 2023

The problem I am seeing if we enable e2e on push event in the development branch is that we (as a reviewer) couldn't verify the hunters don't break before merging the PR right?

Yes. Perhaps we could add the workflow_dispatch handler for the e2e workflow and make it a part of the QA process so that QA engineer could run e2e tests manually before approving.

@0x4007
Copy link
Member

0x4007 commented Sep 12, 2023

The problem I am seeing if we enable e2e on push event in the development branch is that we (as a reviewer) couldn't verify the hunters don't break before merging the PR right?

Yes. Perhaps we could add the workflow_dispatch handler for the e2e workflow and make it a part of the QA process so that QA engineer could run e2e tests manually before approving.

Great idea! Any scope creep (this) can be spun off into a separate task though, so that we can merge asap?

package.json Show resolved Hide resolved
@0x4007
Copy link
Member

0x4007 commented Sep 12, 2023

The problem I am seeing if we enable e2e on push event in the development branch is that we (as a reviewer) couldn't verify the hunters don't break before merging the PR right?

Yes. Perhaps we could add the workflow_dispatch handler for the e2e workflow and make it a part of the QA process so that QA engineer could run e2e tests manually before approving.

Great idea!

I actually have hard time running the tests getting thrown: "Exceeded timeout of 10000 ms for a hook error all the time:

We have six hours to run tests. I don't see how timeout is an issue. Just increase the timeout time?

@whilefoo
Copy link
Collaborator Author

I will fix the tests because there were some changes in between, make timeout 6 hours and add workflow

@whilefoo
Copy link
Collaborator Author

Yes. Perhaps we could add the workflow_dispatch handler for the e2e workflow and make it a part of the QA process so that QA engineer could run e2e tests manually before approving.

It seems you can only manually run workflows on a branch and not PR

@rndquu
Copy link
Member

rndquu commented Sep 13, 2023

The problem I am seeing if we enable e2e on push event in the development branch is that we (as a reviewer) couldn't verify the hunters don't break before merging the PR right?

Yes. Perhaps we could add the workflow_dispatch handler for the e2e workflow and make it a part of the QA process so that QA engineer could run e2e tests manually before approving.

Great idea! Any scope creep (this) can be spun off into a separate task though, so that we can merge asap?

As far as I understand the plan for the current PR is to fix current e2e tests and add a workflow that runs them

@rndquu
Copy link
Member

rndquu commented Sep 13, 2023

Yes. Perhaps we could add the workflow_dispatch handler for the e2e workflow and make it a part of the QA process so that QA engineer could run e2e tests manually before approving.

It seems you can only manually run workflows on a branch and not PR

Let's keep it simple, I think it's enough (for start) to have an e2e workflow with the workflow_dispatch handler. At least we would be able to fetch bounty hunter's PRs and run e2e tests against our own test orgs. We can modify the e2e workflow later to run on forked repos.

@0x4007
Copy link
Member

0x4007 commented Sep 22, 2023

Hey @whilefoo its been over a month. Why don't we leave it with a simple implementation so that we can merge asap.

@whilefoo
Copy link
Collaborator Author

Successful workflow run: https://github.com/ubiquity-whilefoo/ubiquibot/actions/runs/6290628334

@0xcodercrane if you don't have any comments, let's merge this

@0x4007
Copy link
Member

0x4007 commented Sep 24, 2023

Next we should definitely test every incentive cause those are the most important features.

@0x4007
Copy link
Member

0x4007 commented Sep 25, 2023

Successful workflow run: https://github.com/ubiquity-whilefoo/ubiquibot/actions/runs/6290628334

@0xcodercrane if you don't have any comments, let's merge this

Why do some take so long to run? Like start and stop taking 98 seconds?

@0x4007 0x4007 mentioned this pull request Sep 25, 2023
LOG_ENVIRONMENT: "production"
SUPABASE_URL: ${{ secrets.SUPABASE_URL }}
SUPABASE_KEY: ${{ secrets.SUPABASE_KEY }}
X25519_PRIVATE_KEY: "QCDb30UHUkwJAGhLWC-R2N0PiEbd4vQY6qH2Wloybyo"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be exposed? Not sure exactly what it is used for.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's okay, it must be the same because the test's config wallet private key in encrypted with this private key

@0x4007 0x4007 enabled auto-merge September 25, 2023 18:55
@whilefoo
Copy link
Collaborator Author

Why do some take so long to run? Like start and stop taking 98 seconds?

It's a long test. Also there is some delay between because Github sometimes doesn't include latest comments right away so sometimes even with the delay it fails

@rndquu rndquu mentioned this pull request Sep 29, 2023
@Keyrxng Keyrxng mentioned this pull request Oct 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automated QA: End-to-end tests
5 participants