UI Test CI

[0x4007]

Depends on https://github.com/ubiquity/ubiquity-dollar/issues/833

We should prepare UI smoke tests that check that there are no console errors when a new page is opened.

As a part of this issue we should create a new github workflow that runs UI smoke tests (using https://github.com/ubiquity/scraper-kernel) that check that there are no console errors when the following web pages are opened:

1. Home (https://uad.ubq.fi/)
2. Markets (https://uad.ubq.fi/markets)
3. Pool (implemented in https://github.com/ubiquity/ubiquity-dollar/issues/833)

Original description: We should setup Puppeteer on CI to open every view and look for thrown errors.

1. We can iteratively improve the sophistication of the UI tests, but I think this could catch some low hanging fruit/errors.
2. Next we could click all buttons and look for errors.

Inspired by: https://github.com/ubiquity/ubiquity-dollar/issues/253

I have a really good scraper kernel here.

[codeawayaks]

You can assign this to me.

[sergfeldman]

You can assign this to me.

@codeawayaks You commented on 20+ GitHub issues that you want to take it. One developer should solve one bounty at a time to minimize blocking other developers to effectively move forward. Which 1 bounty do you want to take?

[pwilson77]

@sergfeldman you can assign this issue to me

[0x4007]

Can you take a look at the kernel and let me know if you have questions before accepting the bounty? To be honest I think I'll need to work directly with you to make this go smoothly. You're probably going to need to be familiar with Puppeteer to perform well on this.

[pwilson77]

Sure let me take a look at the kernel

[0x4007]

Basically, you need to organize the page scraping/testing logic in src/pages and it maps to the URL structure (can also use wildcards "*")

If you want to write some test page scraping logic, I suggest that you match the function signature of the GitHub scraper controller (it's the latest page logic I have been working on)

The scraper automatically exposes Puppeteer.Browser and Puppeteer.Page which will allow you to do everything you need to manipulate the page with puppeteer.

[pwilson77]

hi sorry for the late response, so am basically just organizing the test logic or?

[0x4007]

I'm going to try and merge the kernel with the initial tests so I'm taking this bounty from the pool.

[kgelpes]

Is this issue open?

[sergfeldman]

Is this issue open?

@kgelpes This issue is already assigned, so not available to the bounty hunters

[0x4007]

@kgelpes This issue is already assigned, so not available to the bounty hunters

Technically this is correct, but I would be open to letting @kgelpes try this but we would probably need to redefine it a little bit.

The vision is to set up Puppeteer on GitHub Actions to automatically run on CI. I think that could be broken into separate bounties:

1. Build Puppeteer code to crawl the UI. + tag a target on the components for the Puppeteer code to click and test. i.e. [data-puppeteer="click"]
2. Puppeteer code should be ported to GItHub Actions to be invoked automatically as part of CI.

@kgelpes are you familiar with Puppeteer? If so, I could make 1. into a new bounty.

[kgelpes]

@kgelpes This issue is already assigned, so not available to the bounty hunters

Technically this is correct, but I would be open to letting @kgelpes try this but we would probably need to redefine it a little bit.

The vision is to set up Puppeteer on GitHub Actions to automatically run on CI. I think that could be broken into separate bounties:

1. Build Puppeteer code to crawl the UI. + tag a target on the components for the Puppeteer code to click and test. i.e. [data-puppeteer="click"]
2. Puppeteer code should be ported to GItHub Actions to be invoked automatically as part of CI.

@kgelpes are you familiar with Puppeteer? If so, I could make 1. into a new bounty.

I can create tests for puppeteer to test simple stuff like clicking buttons, also taking screenshots so that we can check there's no visual anomalies on builds

[olich97]

Hello @pavlovcik, would you like to consider using playwright instead of puppeteer for UI testing in this case? I think it could be a nice fit for this project as playwright has an easy and clean way to writing tests and integrates gracefully with GitHub CI, more info:

• Writing tests
• CI GitHub Actions
• Capture/check console errors (example)

[ubiquibot[bot]]

Available commands

- /assign: Assign the origin sender to the issue automatically.
- /unassign: Unassign the origin sender from the issue automatically.
- /help: List all available commands.
- /payout: Disable automatic payment for the issue.
- /multiplier: Set bounty multiplier (for treasury)
- /allow: Set access control. (Admin Only)
- /wallet: <WALLET_ADDRESS | ENS_NAME>: Register the hunter's wallet address. 
  ex1: /wallet 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 
  ex2: /wallet vitalik.eth

@olich97

[ubiquibot[bot]]

Available commands

- /assign: Assign the origin sender to the issue automatically.
- /unassign: Unassign the origin sender from the issue automatically.
- /help: List all available commands.
- /payout: Disable automatic payment for the issue.
- /multiplier: Set bounty multiplier (for treasury)
- /allow: Set access control. (Admin Only)
- /wallet: <WALLET_ADDRESS | ENS_NAME>: Register the hunter's wallet address. 
  ex1: /wallet 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 
  ex2: /wallet vitalik.eth

@olich97

[ubiquibot[bot]]

Available commands

- /assign: Assign the origin sender to the issue automatically.
- /unassign: Unassign the origin sender from the issue automatically.
- /help: List all available commands.
- /payout: Disable automatic payment for the issue.
- /multiplier: Set bounty multiplier (for treasury)
- /allow: Set access control. (Admin Only)
- /wallet: <WALLET_ADDRESS | ENS_NAME>: Register the hunter's wallet address. 
  ex1: /wallet 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 
  ex2: /wallet vitalik.eth

@olich97

[0x4007]

No because we have existing infrastructure with puppeteer. Check @ubiquity/scraper-kernel. The reason why puppeteer was chosen is because it is developed and supported by the chrome team.

[olich97]

Understood, many thanks for the clarification 👍

[PhantomCracker]

Hello @pavlovcik , I would like to work on this. Do you think that we can schedule a call or to chat somewhere out of github?

[molecula451]

/start

[ubiquibot[bot]]

Skipping /start since no time labels are set to calculate the timeline

[molecula451]

i can tackle this one after #685 closes

[rndquu]

This task is not ready because we first need to update UI to follow the diamond contracts deploy

[molecula451]

This task is not ready because we first need to update UI to follow the diamond contracts deploy

let's work on it together

[0x4007]

This task is not ready because we first need to update UI to follow the diamond contracts deploy

@rndquu is there an update on this?

[rndquu]

This task is not ready because we first need to update UI to follow the diamond contracts deploy

@rndquu is there an update on this?

@molecula451 will you handle this one https://github.com/ubiquity/ubiquity-dollar/issues/731 ? If not then I'll take it

[molecula451]

This task is not ready because we first need to update UI to follow the diamond contracts deploy

@rndquu is there an update on this?

@molecula451 will you handle this one #731 ? If not then I'll take it

Yes I will handle the UI at #731 asap. I would have tell you otherwise

[0x4007]

• #731 appears to be completed!

[rndquu]

• Add UI diamond hook #731 appears to be completed!

The UI is still broken so the current issue is still blocked

I will add new UI related tasks today

[molecula451]

Unfortunately the #731 was mislead, because the specs mention to add a hook, keep the hook, or fix it, in any case, this was never the case, the contracts are being fetching in another way, but this was all part of the debug. We would have never known the bad state of this hook without working up through all those opened (now closed) issues.