60da9e470a
* direct connector builder to first workspace and fix routing * add connector builder namespace and actions * track connector builder start event * track api url created event * track auth method select * fix action description * track user input events * track sidebar events * track stream creation * track copying stream * track stream delete * track stream test success/failure * track download yaml and fix yaml file name * track events for switching between ui/yaml * track events for overwriting and merging schemas * fix stream test failure/success events and add tracking of test initiation * do not send schema contents in events * track when stream is selected from testing panel * fix typo * handle initial setup completed in e2e tests * add warning about not putting sensitive info into URL fields * fix before in e2e test
Running an interactive Cypress session with npm run cypress:open
The most useful way to run tests locally is with the cypress open command. It opens a dispatcher window that lets you select which tests and browser to run; the Electron browser (whose devtools will be very familiar to chrome users) opens a child window, and having both cypress windows grouped behaves nicely when switching between applications. In an interactive session, you can use it.skip and it.only to focus on the tests you care about; any change to the source file of a running test will cause tests to be automatically rerun. At the end of a test run, the web page is left "dangling" with all state present at the end of the last test; you can click around, "inspect element", and interact with the page however you wish, which makes it easy to incrementally develop tests.
By default, this command is configured to visit page urls from port 3000 (as used by a locally-run dev server), not port 8000 (as used by docker-compose's webapp service). If you want to run tests against the dockerized UI instead, leave the webapp docker-compose service running in step 4) and start the test runner with CYPRESS_BASE_URL=http://localhost:8000 npm run cypress:open in step 8).
Except as noted, all commands are written as if run from inside the airbyte-webapp-e2e-tests/ directory.
Steps:
- If you have not already done so, run
npm installto install the e2e test dependencies. - Build the OSS backend for the current commit with
SUB_BUILD=PLATFORM ../gradlew clean build. - Create the test database:
npm run createdbsourceandnpm run createdbdestination. - When running the connector builder tests, start the dummy API server:
npm run createdummyapi - Start the OSS backend:
BASIC_AUTH_USERNAME="" BASIC_AUTH_PASSWORD="" VERSION=dev docker compose --file ../docker-compose.yaml up. If you want, follow this withdocker compose stop webappto turn off the dockerized frontend build; interactive cypress sessions don't use it. - The following two commands will start a separate long-running server, so open another terminal window. In it,
cdinto theairbyte-webapp/directory. - If you have not already done so, run
npm installto install the frontend app's dependencies. - Start the frontend development server with
npm start. - Back in the
airbyte-webapp-e2e-tests/directory, start the cypress test runner withnpm run cypress:open.
Reproducing CI test results with npm run cypress:ci or npm run cypress:ci:record
Unlike npm run cypress:open, npm run cypress:ci and npm run cypress:ci:record use the dockerized UI (i.e. they expect the UI at port 8000, rather than port 3000). If the OSS backend is running but you have run docker-compose stop webapp, you'll have to re-enable it with docker-compose start webapp. These trigger headless runs: you won't have a live browser to interact with, just terminal output.
Except as noted, all commands are written as if run from inside the airbyte-webapp-e2e-tests/ directory.
Steps:
- If you have not already done so, run
npm installto install the e2e test dependencies. - Build the OSS backend for the current commit with
SUB_BUILD=PLATFORM ../gradlew clean build. - Create the test database:
npm run createdbsourceandnpm run createdbdestination. - When running the connector builder tests, start the dummy API server:
npm run createdummyapi - Start the OSS backend:
BASIC_AUTH_USERNAME="" BASIC_AUTH_PASSWORD="" VERSION=dev docker compose --file ../docker-compose.yaml up. - Start the cypress test run with
npm run cypress:ciornpm run cypress:ci:record.
Test setup
When the tests are run as described above, the platform under test is started via docker compose on the local docker host. To test connections from real sources and destinations, additional docker containers are started for hosting these. For basic connections, additional postgres instances are started (createdbsource and createdbdestination).
For testing the connector builder UI, a dummy api server based on a node script is started (createdummyapi). It is providing a simple http API with bearer authentication returning a few records of hardcoded data. By running it in the internal airbyte network, the connector builder server can access it under its container name.
The tests in here are instrumenting a Chrome instance to test the full functionality of Airbyte from the frontend, so other components of the platform (scheduler, worker, connector builder server) are also tested in a rudimentary way.