feat: add end-to-end tests for ArcadeDB Studio database creation and …#2290
feat: add end-to-end tests for ArcadeDB Studio database creation and …#2290
Conversation
There was a problem hiding this comment.
Summary of Changes
Hello @robfrank, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces comprehensive end-to-end (E2E) testing for ArcadeDB Studio using Playwright. It establishes a new testing framework, integrates it into the CI/CD pipeline via GitHub Actions, and provides initial test cases to validate core functionalities like database creation and data querying, significantly enhancing the reliability of the Studio application.
Highlights
- E2E Testing Framework: Implemented a new end-to-end (E2E) testing suite for ArcadeDB Studio using Playwright, including core configuration files (
playwright.config.ts,package.json) and a dedicatede2e-studiodirectory. - Automated Server Setup: Included scripts within
package.jsonto automatically start and stop a Dockerized ArcadeDB server instance, pre-configured with a root password and an imported 'Beer' database, ensuring a consistent and isolated testing environment. - Initial Test Cases: Developed two foundational E2E tests: one to verify the successful creation of a new database (
create-database.spec.ts) and another to validate querying capabilities and graph visualization within the 'Beer' database (query-beer-database.spec.ts). - Documentation: Provided a
README.mdfile within thee2e-studiodirectory, detailing setup, prerequisites, and instructions for running and debugging the E2E tests locally. - CI/CD Integration: Integrated the new E2E tests into the existing GitHub Actions workflow (
mvn-test.yml) by adding astudio-e2e-testsjob, which handles Node.js setup, Docker image restoration, Playwright browser installation, headless test execution, and artifact uploading.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces end-to-end tests for ArcadeDB Studio using Playwright, which is a valuable addition for ensuring the stability and correctness of the UI. The setup in package.json and playwright.config.ts seems appropriate for running these tests both locally and in CI. The initial test cases cover basic database creation and querying, providing a good starting point. The README is clear and helpful for setting up and running the tests. The package-lock.json is correctly included. Overall, this is a positive step for the project's testing infrastructure. The review comments below highlight areas where selectors could be made more robust for better test maintainability.
| await expect(page.getByText('Connected as').first()).toBeVisible(); | ||
|
|
||
| // Navigate to Database tab (second tab with database icon) | ||
| await page.getByRole('tab').nth(1).click(); |
There was a problem hiding this comment.
| await expect(page.getByRole('dialog', { name: 'Create a new database' })).not.toBeVisible(); | ||
|
|
||
| // Verify the new database is selected in the dropdown | ||
| await expect(page.locator('select').first()).toContainText('e2e-studio'); |
There was a problem hiding this comment.
Using locator('select').first() to select the database dropdown is fragile. If there are other select elements on the page, this selector might break or select the wrong element. Consider using a more specific selector, such as getByLabel('root') (as used in the query test) or a selector based on a unique data attribute if available.
| await queryTextarea.fill('SELECT FROM Beer LIMIT 10'); | ||
|
|
||
| // Execute the query by clicking the execute button | ||
| await page.getByRole('button', { name: '' }).first().click(); |
There was a problem hiding this comment.
Using getByRole('button', { name: '' }).first() to select the execute button is very fragile as it relies on the button having no accessible name and being the first such button. This will likely break if the UI changes or other nameles buttons are added. Consider using a more robust selector, such as getByRole('button', { name: 'Execute' }) (if the button has this text), a selector based on an icon (e.g., getByRole('button', { name: 'Run query' }) if it has an icon with that accessible name), or a selector based on a unique data attribute if available.
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
refs #2291
This pull request introduces end-to-end (E2E) testing for ArcadeDB Studio using Playwright. It includes the addition of a new GitHub Actions workflow for running the tests, setup and configuration files for the testing framework, and two initial test cases for database creation and querying functionality.
Workflow Integration
.github/workflows/mvn-test.yml: Added a newstudio-e2e-testsjob to automate the execution of E2E tests. This includes setting up Node.js, restoring Docker images, installing Playwright browsers, running tests in headless mode, and uploading test artifacts.Test Framework Setup
e2e-studio/package.json: Defined scripts for running tests, starting/stopping the ArcadeDB server, installing Playwright browsers, and generating test reports. Added dependencies for Playwright and server readiness checks.e2e-studio/playwright.config.ts: Configured Playwright to run tests in parallel, retry failed tests in CI environments, and use a web server running ArcadeDB Studio locally.Documentation
e2e-studio/README.md: Added documentation for setting up and running the E2E tests, including prerequisites, test commands, and file descriptions.Test Cases
e2e-studio/tests/create-database.spec.ts: Implemented a test for creating a new database in ArcadeDB Studio, verifying the database creation dialog and schema visibility.e2e-studio/tests/query-beer-database.spec.ts: Added a test for querying the Beer database, ensuring the correct number of vertices are displayed in the graph tab.