Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In
`@packages/cli/src/commands/integrations/tests/add-integration.redshift.test.ts`:
- Around line 51-213: The tests never exercise the "Enable SSH tunnel" and
"Enable SSL" affirmative path; add at least one new test (or extend an existing
it block) that, after calling createIntegration(...) and fillBaseFields(), when
prompted for "Enable SSH tunnel: (y/N)" and "Enable SSL: (y/N)" answers 'y',
supplies the SSH fields (e.g., bastion host, bastion user, bastion port, private
key or key path) via the same screen.type()/keypress flows used elsewhere,
awaits the promise, then reads the generated YAML and asserts the resulting
metadata contains the SSH and SSL properties (matching the app's metadata keys
used when writing the file); use the same helpers (createIntegration,
fillBaseFields, screen.next) and the mocked UUID to keep consistency.
- Around line 89-108: The inline multiline snapshots passed to
expect(yamlContent).toMatchInlineSnapshot(...) and
expect(envContent).toMatchInlineSnapshot(...) should be wrapped with dedent(...)
to normalize indentation; add an import for dedent from 'ts-dedent' if missing
and replace the raw backtick snapshot arguments with dedent(`...`) for each
toMatchInlineSnapshot occurrence (also update the other two similar blocks
referenced around the file), keeping the exact snapshot text but wrapped with
dedent.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/cli/src/commands/integrations/tests/add-integration.mysql.test.ts`:
- Around line 99-100: The test snapshot for yamlContent is asserting a schema
header that points to a feature branch ref
(refs/heads/tk/integrations-config-file-schema); update the YAML generator (the
code that produces the value asserted by yamlContent) to emit a stable schema
URL (for example using the main branch or a tagged release/commit SHA in the
raw.githubusercontent.com path instead of the feature-branch ref), then
regenerate/update the inline snapshots in the tests to match the new stable
header.
- Around line 210-243: Read the current .env using readDotEnv(envFilePath)
before calling updateDotEnv and assert that the CA secret key
AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__CACERTIFICATETEXT contains the certificate
value created earlier by the test flow (i.e., verify createIntegration persisted
the multiline cert); then proceed with updateDotEnv and the existing post-update
assertion to validate the roundtrip. Ensure you reference the readDotEnv and
updateDotEnv helpers and the env key
AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__CACERTIFICATETEXT when adding the
pre-update assertion.

---

Duplicate comments:
In
`@packages/cli/src/commands/integrations/tests/add-integration.clickhouse.test.ts`:
- Around line 183-205: The test adds a ClickHouse integration using
fillBaseFields() and verifies the YAML but misses asserting the generated .env
contents; after the existing await promise line in the test (the variable named
promise), read the created .env file (using the same filePath root or helper
used elsewhere) and assert it contains the expected environment variable mapping
for AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__PASSWORD => the plain password value
supplied by fillBaseFields(); update the test to include this .env assertion so
both the YAML env reference and the actual .env secret are verified.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.sql-server.test.ts`:
- Around line 109-168: The test updates the integration password via interactive
prompts but never asserts the .env file content; add a check after awaiting
promise to read the env file (use envFilePath and readFile) and assert the env
variable is still present and unchanged (e.g., equals or contains
"ID001__PASSWORD=secret-pass\n") so the password env var wasn't corrupted or
duplicated by editIntegration; locate this assertion near the existing
yamlContent check in the 'updates host and database when user types new values'
test.
- Around line 170-247: In the test "adds SSH fields when SSH is enabled on a
plain integration" add a check that the .env file was not modified after running
editIntegration: after awaiting promise, read envFilePath (the .env variable
used in the test) and assert its contents still include
"ID001__PASSWORD=secret-pass" (or match the original .env string), ensuring
enabling SSH preserved the .env file; keep this assertion next to the existing
yamlContent assertion.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@packages/cli/src/commands/integrations/tests/edit-integration.dremio.test.ts`:
- Around line 43-95: Add an assertion to verify the .env file was preserved
after running editIntegration: after awaiting promise and reading yamlContent,
read the env file (envFilePath) and assert its contents still include the
original token line ("DR_ID_001__TOKEN=secret-token\n"); reference the test case
"edits dremio integration keeping all defaults" and the editIntegration call so
you place the new check after the existing YAML assertion to confirm .env
preservation.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.mindsdb.test.ts`:
- Around line 182-262: The test "adds SSH fields when SSH is enabled on a plain
integration" currently declines the "Enable SSL" prompt; update the test to also
enable SSL by answering 'y' to the "Enable SSL: (y/N)" prompt, fill in any
subsequent SSL-related prompts (e.g., certificate/CA path or verify toggle) via
screen.type + screen.keypress, and then update the final YAML assertion (the
inline snapshot) to include sslEnabled: true and the corresponding SSL metadata
fields added by editIntegration; reference the editIntegration invocation and
the final YAML snapshot in the test to locate where to change the interactions
and expected output.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/cli/src/commands/integrations/tests/add-integration.mysql.test.ts`:
- Around line 78-251: Add a new test case to the MySQL integration tests that
exercises secrets with special characters (e.g. '=', '#', quotes,
leading/trailing spaces) to validate dotenv/YAML serialization; copy the pattern
from the existing "creates mysql integration with SSL enabled" test (use
createIntegration, fillBaseFields, screen flows to enable SSL and provide CA
fields), but supply a password and caCertificateText containing special
characters (or write the multiline/complex value directly via updateDotEnv),
then assert the written integrations YAML contains the env: ref and that
readDotEnv returns the exact original secret values (use updateDotEnv/readDotEnv
imported from ../../../utils/dotenv and the same mock UUID setup via
crypto.randomUUID to keep env var names stable).
- Around line 23-24: The temp directory name uses only Date.now(), which can
collide in parallel tests; update the tempDir creation in the
add-integration-mysql-test to append a unique random component (for example use
fs.mkdtemp with a prefix like join(tmpdir(), 'add-integration-mysql-test-') or
append process.pid + crypto.randomUUID()/Math.random()) instead of relying
solely on Date.now(), and keep the existing mkdir usage or remove it if using
mkdtemp which already creates the directory; update the tempDir variable
assignment accordingly so tests get isolated directories.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.databricks.test.ts`:
- Around line 43-268: Add two new tests in this file: one failing-path that
calls editIntegration({ file: filePath, envFile: envFilePath, id: 'unknown-id'
}) and asserts the CLI shows an appropriate error (or the promise rejects) when
the id is not found (use screen.next()/screen.getScreen() and expect
rejection/err message), and one special-character test that uses EXISTING_YAML
as base but types values containing YAML-significant characters (e.g., name:
"Prod: Databricks – v1", token with = and spaces or quotes, httpPath with
leading '|' or ':' and/or newline chars) via screen.type(...) through the edit
flow, then assert the resulting integrations.yaml and .env preserve/serialize
those special characters correctly (check both yamlContent and envContent).
Target the editIntegration flow and assertions already used in nearby tests to
locate insertion points.

---

Duplicate comments:
In
`@packages/cli/src/commands/integrations/tests/edit-integration.databricks.test.ts`:
- Around line 39-41: The afterEach teardown currently removes tempDir but
doesn't clear mutated env vars; update the afterEach in
edit-integration.databricks.test.ts to explicitly remove any process.env keys
matching the Databricks token pattern (e.g., process.env.DB_ID_001__TOKEN or the
/^DB_.*__TOKEN$/ pattern) after each test so later tests don't see leaked
values; locate the afterEach block and add logic to iterate process.env keys
that match that pattern and delete them (or restore any saved originals if you
saved pre-test copies) to ensure global env is cleaned up between tests.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@packages/cli/src/commands/integrations/tests/add-integration.alloydb.test.ts`:
- Around line 119-173: In the "creates alloydb integration with SSH tunnel
enabled" test, add an assertion that reads the env file at envFilePath (using
readFile(envFilePath, 'utf-8')) and verifies the secret was written—e.g. that
the generated key AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__PASSWORD (matching the
mocked crypto.randomUUID) and its value are present—so the test fails if the SSH
branch omits writing to the .env; place this check after awaiting promise and
before or alongside the YAML snapshot assertion to mirror the other tests
(createIntegration, fillBaseFields, promise, filePath, envFilePath).

In
`@packages/cli/src/commands/integrations/tests/add-integration.databricks.test.ts`:
- Around line 138-188: The test for SSH-enabled Databricks integration checks
only the generated YAML but misses asserting the .env file output; update the
test (in create databricks integration with SSH tunnel enabled) to read the env
file at envFilePath (use readFile(envFilePath, 'utf-8')) after await promise and
assert it contains the expected env var entry whose name is derived from the
mocked UUID (mockUUID) and shown in the YAML as
AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__TOKEN (or the exact env var string used by
the code), so add an expect on that env content to catch token-write
regressions.

In
`@packages/cli/src/commands/integrations/tests/add-integration.materialize.test.ts`:
- Around line 73-200: Add tests for Materialize flow to cover invalid-port
validation, required-field retry/abort, and special-character inputs: in the
test suite around createIntegration and fillBaseFields add one test that types
an invalid port (e.g., "not-a-number") via screen.type, asserts the
validation/error prompt is shown, then corrects it and completes the flow
(assert YAML contains corrected "port"); add a test that leaves a required field
blank (e.g., host or user), assert the CLI reprompts and test both retry
(provide valid value) and abort (simulate ctrl+c or appropriate abort key and
assert no file written); add a test that uses special characters in
name/password (e.g., spaces, punctuation, unicode) and verify the written
integrations YAML and .env preserve/escape those characters correctly. Target
functions/objects: createIntegration, fillBaseFields, screen, readFile and the
test cases named 'creates materialize integration...' to place these new
assertions.

In
`@packages/cli/src/commands/integrations/tests/add-integration.mongodb.test.ts`:
- Around line 98-253: The tests are missing a case that enables SSL for MongoDB;
add a new "creates mongodb integration with SSL enabled" test in the same file
that uses createIntegration({ file, envFile }), calls fillMongoCredentials(),
then simulates enabling SSL via the shared prompts (use screen to answer 'y' on
the "Enable SSL" prompt instead of declineSshAndSsl()), awaits the promise, and
then assert that the written YAML (readFile) contains the ssl-related metadata
fields (e.g., sslEnabled/sslCert/sslKey or whatever the schema uses) and that
the .env contains the corresponding cert/key env variables; reuse helpers
already in the file (fillMongoCredentials, createIntegration, screen, tempDir,
readFile) and mirror the structure of the existing SSH test for consistency.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.athena.test.ts`:
- Around line 42-94: Add an assertion that the .env file contains the expected
secret after running the test: read envFilePath (the variable in this test) and
assert it equals "ATH_ID_001__SECRET_ACCESS_KEY=secret-key\n" (or contains that
line) after awaiting promise in the "edits athena integration keeping all
defaults" test; reference the test variables filePath, envFilePath,
EXISTING_YAML and the env var key ATH_ID_001__SECRET_ACCESS_KEY to locate where
to add the check.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.big-query.test.ts`:
- Around line 148-152: The test currently asserts env contents but doesn't
document that switching auth to OAuth leaves the previous
BQ_ID_001__SERVICE_ACCOUNT env var in the file due to append-only behavior;
update the test by either renaming the test case (in
edit-integration.big-query.test.ts) to explicitly state "append-only: stale
SERVICE_ACCOUNT remains after switching to OAuth" or add a concise inline
comment above the expect(envContent) assertion explaining that the
BQ_ID_001__SERVICE_ACCOUNT is intentionally retained and not removed when
switching auth methods.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.databricks.test.ts`:
- Around line 42-268: Tests only cover happy paths for editIntegration; add at
least one error-path test and one edge-case test. Create a new test that calls
editIntegration({ file, envFile, id: 'non-existent-id' }) and asserts the CLI
shows an appropriate error message or the promise rejects (check behavior of
editIntegration) to cover unknown id handling; create another test that uses
EXISTING_YAML but writes an env value and HTTP Path containing special
characters (e.g., spaces, slashes, symbols) and assert the written
integrations.yaml and .env preserve/escape them correctly (reference the
existing tests' use of editIntegration, EXISTING_YAML, tempDir, and
DB_ID_001__TOKEN to locate where to add these cases).

In
`@packages/cli/src/commands/integrations/tests/edit-integration.materialize.test.ts`:
- Around line 113-176: The test edits the Materialize integration but doesn't
assert the .env file contents; after awaiting promise (the editIntegration call)
add a check that reads envFilePath (use readFile(envFilePath, 'utf-8')) and
expect the returned string to contain the original secret key/value (e.g.,
expect(envContent).toContain('MZ_ID_001__PASSWORD=secret-pass')) to ensure the
.env entry is present/unchanged.
- Around line 49-111: The test edits the Materialize integration but never
asserts the .env file contents; after awaiting promise and reading yamlContent,
also read the envFilePath (using readFile(envFilePath, 'utf-8')) and assert its
content includes the expected environment variable line
"MZ_ID_001__PASSWORD=secret-pass\n" (or use toMatchInlineSnapshot/toEqual like
the other tests) so the test verifies the env-backed password was written/kept
correctly; reference variables: editIntegration, envFilePath, EXISTING_YAML,
MZ_ID_001__PASSWORD.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.mindsdb.test.ts`:
- Around line 181-261: The test for SSH in edit-integration.mindsdb.test.ts
exercises SSH but always declines SSL; update or add a test case that, after
answering the 'Enable SSL: (y/N)' prompt, types 'y' and completes the flow, then
assert that the written YAML (read from filePath) contains the SSL-related
metadata keys (e.g., sslEnabled: true and caCertificateName or other SSL fields
your integration writes). Locate the interactive flow driven by
editIntegration({ file: filePath, envFile: envFilePath, id: 'id-001' }) and the
sequence that reaches the 'Enable SSL: (y/N)' prompt, change the
screen.keypress/keyboard input to enter 'y' and any subsequent SSL inputs, then
add assertions against yamlContent (the variable already used) to verify
sslEnabled and the expected SSL metadata are present.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.spanner.test.ts`:
- Around line 42-90: Add an assertion to verify the .env file contains the
expected env-backed service account after editIntegration completes: after
awaiting promise and before/after reading yamlContent, read envFilePath (the
.env created earlier) and assert it includes the line
"SP_ID_001__SERVICE_ACCOUNT=service-account-data" to ensure the test checks both
YAML and env file updates for the Service Account; locate this near the existing
assertions in the test case that uses editIntegration, filePath, envFilePath,
and EXISTING_YAML.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.sql-server.test.ts`:
- Around line 112-171: The test "updates host and database when user types new
values" updates the YAML to use an env-backed password but doesn't assert the
.env file contents; after awaiting promise and before or after asserting
yamlContent, read the envFilePath (envFilePath variable) and assert its contents
include the expected line "ID001__PASSWORD=secret-pass" (or exact string used in
the other test) to mirror the first test's .env assertion, referencing the
existing envFilePath variable and the editIntegration invocation to locate where
to add the check.
- Around line 173-250: The test "it adds SSH fields when SSH is enabled on a
plain integration" doesn't assert the .env file after running editIntegration;
add a check after awaiting promise that reads envFilePath (use
readFile(envFilePath, 'utf-8')) and assert it contains the expected secret line
(e.g., expect(envContent).toContain('ID001__PASSWORD=secret-pass') or an inline
snapshot) so the test verifies the .env was written/unchanged as expected.

---

Duplicate comments:
In
`@packages/cli/src/commands/integrations/tests/add-integration.big-query.test.ts`:
- Around line 25-136: The test suite add-integration.big-query.test.ts lacks
negative and edge-case coverage; add new tests alongside the existing "creates
big-query integration..." cases that call createIntegration to verify failure
behavior for (1) invalid Service Account JSON (e.g., malformed JSON) by
asserting the command fails and no files are written, (2) missing required
Google OAuth fields (omit project, clientId, or clientSecret one at a time) by
asserting the CLI shows validation errors and exits non-zero, and (3) inputs
containing special characters (e.g., quotes, newlines, env-key-unfriendly chars)
to ensure env file escaping and YAML generation handle them; reference the
existing test helpers/screen interactions and the createIntegration promise
pattern so the new tests reuse screen.type(), screen.keypress(), await
screen.next(), and readFile assertions to confirm correct error messages or
properly escaped outputs.

In
`@packages/cli/src/commands/integrations/tests/add-integration.clickhouse.test.ts`:
- Around line 149-204: The test for SSH-enabled ClickHouse currently asserts the
YAML but doesn't verify the .env secret write; after awaiting promise and
before/after reading yamlContent, read the envFilePath (use
readFile(envFilePath, 'utf-8')) and assert it contains the generated env var
key/value derived from mockUUID (the same env var referenced in YAML:
AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__PASSWORD) so the secret was written;
update the test that uses mockUUID, envFilePath, createIntegration, and readFile
to include this .env content assertion.

In `@packages/cli/src/commands/integrations/tests/add-integration.dremio.test.ts`:
- Around line 56-145: The test file only covers the happy path for Dremio; add
unit tests exercising validation and edge cases: create three new tests (e.g.,
"rejects invalid port", "rejects empty required fields", "handles token with
special characters stored as env ref") that call createIntegration({ file,
envFile }) and reuse the existing helpers/mockUUID/vi.spyOn(crypto,
'randomUUID') and fillBaseFields(); for the invalid-port test drive the
interactive prompts via screen.type to supply a non-numeric or out-of-range port
and assert the CLI shows a validation error or re-prompts (use
screen.next()/screen.getScreen() expectations and assert the promise rejects or
stalls as appropriate); for empty-required-fields simulate submitting blanks for
required prompts (name/host/token) and assert validation messages; for
special-character token type a token with symbols, ensure it is saved to the
.env (envFilePath) and that the integrations YAML uses the env:<KEY> ref as in
existing tests.

In
`@packages/cli/src/commands/integrations/tests/add-integration.mariadb.test.ts`:
- Around line 77-237: Add two tests to the existing suite that use the same
helpers (createIntegration, fillBaseFields, screen, tempDir, readFile) and
mocked UUID (vi.spyOn(crypto, 'randomUUID')). First test: "invalid port then
corrected" — start createIntegration, fillBaseFields, when prompted for "Enable
SSH tunnel:" skip, at "Enable SSL:" skip, at "Port:" type an invalid value like
"not-a-number", assert the interactive prompt shows a validation/error message,
then type the corrected numeric port "3306" and proceed; finally assert the YAML
contains port: "3306" and .env unchanged. Second test: "password and
caCertificateText with special chars" — createIntegration, fillBaseFields, skip
SSH, enable SSL, for "CA Certificate:" provide a value with quotes and newlines
(e.g. "line1\n\"quoted\" line2"), and for the password field input a value
containing quotes/newlines as well when prompted; await completion and assert
the YAML references env vars (env:UUID__PASSWORD and
env:UUID__CACERTIFICATETEXT) and the .env file contains the exact password and
the multi-line/quoted certificate value preserved/escaped correctly (including
literal newlines), so the shared prompt + .env serialization path is exercised
under escaping and special characters.

In
`@packages/cli/src/commands/integrations/tests/add-integration.redshift.test.ts`:
- Around line 50-212: The tests never exercise the SSH/SSL branches; update the
Redshift test cases that call createIntegration and use
screen.next/screen.keypress so at least one flow answers 'y' to the "Enable SSH
tunnel" prompt and another answers 'y' to the "Enable SSL" prompt. Concretely,
modify one of the flows (e.g., the IAM-role test) to press 'y' when the SSH
prompt appears and adjust its yamlContent snapshot to include the SSH-related
metadata field(s) emitted by the code (look for metadata keys in the output
produced by createIntegration), and modify a different flow (e.g., the
individual-credentials test) to press 'y' for the SSL prompt and update that
test's yamlContent snapshot to include the SSL-related metadata field(s); keep
the existing username/password test unchanged. Ensure you still call
fillBaseFields, await promise, and update any expected envContent snapshots if
enabling SSH/SSL changes environment variable output.

In
`@packages/cli/src/commands/integrations/tests/add-integration.spanner.test.ts`:
- Around line 25-126: Add a new prompt-driven test case that exercises entering
a JSON-shaped service account containing quotes and escaped newlines via the
interactive flow: call createIntegration(...) and use fillBaseFields() but when
the prompt for "Service Account (JSON):" appears use screen.type to enter a
quoted JSON string with escaped newlines and quotes (e.g.
"{\"private_key\":\"line1\\nline2\",\"client_email\":\"x@example.com\"}") and
submit; then await the promise, read the written env file (readFile or
readDotEnv) and assert the env var value equals the exact escaped string stored
by the CLI, and also add a second sub-case that submits an empty/invalid value
to assert validation behavior (expect an error message or retry prompt) so the
interactive validation for the service account field is covered; reference
fillBaseFields, createIntegration, screen.type, readDotEnv/updateDotEnv in your
test additions.

In
`@packages/cli/src/commands/integrations/tests/add-integration.sql-server.test.ts`:
- Around line 30-174: Add a test that calls the existing helper fillBaseFields
with an overrides object to exercise special characters / edge input (e.g., name
containing symbols, host with uncommon chars, and a password with
punctuation/whitespace) and assert the resulting integrations YAML and .env
contain properly escaped/encoded values; update or add an it(...) in the SQL
Server suite that uses fillBaseFields({ name: 'My DB `#1` — test', host:
'db.exämple.com', password: 'p@$$ word!'}), then run through the same steps
(enable/disable SSH as desired) and include expectations that readFile(filePath,
'utf-8') and readFile(envFilePath, 'utf-8') match snapshots or contain the env
ref with the exact special-char password to verify handling of special
characters.

In `@packages/cli/src/commands/integrations/tests/add-integration.trino.test.ts`:
- Around line 182-259: Add a new test (e.g., "creates trino integration with SSH
tunnel and SSL enabled") next to the existing creates trino integration with SSH
tunnel enabled test that follows the same flow (calls createIntegration, awaits
fillBaseFields, navigates prompts) but answers the "Enable SSL: (y/N)" prompt
with "y" and fills any additional SSL prompts that follow; then await the
promise and assert the resulting YAML and .env include SSL-specific fields
(e.g., sslEnabled: true and any ssl certificate/key/config entries) and still
include the SSH fields. Reference the existing test's use of createIntegration,
fillBaseFields, the "Enable SSL: (y/N)" prompt, and the final YAML/env
assertions as the pattern to replicate.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.alloydb.test.ts`:
- Around line 175-256: Add a new test alongside the existing "adds SSH fields
when SSH is enabled on a plain integration" that exercises enabling SSL: call
editIntegration (same as the SSH test), drive the interactive prompts to answer
the SSL question with "y" and provide certificate-related values (e.g., client
cert, client key, ca cert or whatever prompts the CLI shows), then await the
promise and assert the resulting YAML (readFile(filePath, 'utf-8')) includes
sslEnabled: true and the expected certificate fields under metadata. Reuse
EXISTING_YAML, tempDir, envFilePath setup and the screen interaction pattern
from the SSH test to locate where to inject the SSL responses and add the inline
snapshot/assertion for the sslEnabled and cert fields.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.athena.test.ts`:
- Around line 96-150: The test suite is missing a case that verifies the
Workgroup field is persisted; add a new test (or extend the existing 'updates
region when user types new value' test) that types a non-empty workgroup before
submitting and then asserts the written YAML includes metadata.workgroup with
the entered value. Locate the editIntegration invocation and the screen
interactions (screen.next(), screen.type(...), screen.keypress('enter')) and add
a step after the "Workgroup:" prompt to screen.type('my-workgroup') and press
enter, then read the file (readFile(filePath, 'utf-8')) and include an expect
that the YAML contains workgroup: my-workgroup for the integration with id
'ath-id-001' (using EXISTING_YAML fixture and same file/env setup).

In
`@packages/cli/src/commands/integrations/tests/edit-integration.clickhouse.test.ts`:
- Around line 111-174: The test currently declines SSH and SSL; update the
interactive steps in the 'updates host when user types new value' test (the
editIntegration flow using promise, screen, and EXISTING_YAML) to accept both
prompts by replacing the two screen.keypress('enter') calls for "Enable SSH
tunnel: (y/N)" and "Enable SSL: (y/N)" with screen.type('y') followed by
screen.keypress('enter') for each, and then update the final YAML assertion (the
yamlContent / inline snapshot) to include the corresponding metadata flags
(e.g., add metadata.ssh_tunnel: "true" and metadata.ssl: "true" or the project's
canonical field names for SSH/SSL) so the snapshot/assert matches the enabled
options.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.mariadb.test.ts`:
- Around line 175-255: The test "adds SSH fields when SSH is enabled on a plain
integration" is missing coverage for the SSL prompt — update the test in
edit-integration.mariadb.test.ts to answer the "Enable SSL: (y/N)" prompt with
"y" (use screen.type('y') and screen.keypress('enter')) after the SSH prompts,
then update the final YAML assertion (the inline snapshot) to include the
expected SSL metadata (e.g., add sslEnabled: true under metadata or whatever the
integration code writes when SSL is enabled) so the snapshot reflects enabling
SSL.

In `@packages/cli/src/commands/integrations/tests/edit-integration.mysql.test.ts`:
- Around line 175-256: Add a new test in edit-integration.mysql.test.ts (similar
to the existing "adds SSH fields..." test) that exercises enabling SSL: call
editIntegration with the same EXISTING_YAML and env file, use screen to accept
defaults until the "Enable SSL: (y/N)" prompt, type 'y' and fill any
SSL-specific prompts (e.g., sslMode or sslCert fields if present), await the
promise, then read yamlContent and add an inline snapshot asserting the
resulting YAML contains SSL-enabled fields (e.g., sslEnabled: true and any ssl*
entries). Use the same test helpers and symbols: editIntegration, EXISTING_YAML,
screen, yamlContent and expect(...).toMatchInlineSnapshot to mirror the
AlloyDB/MindsDB SSL-enabled tests.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@packages/cli/src/commands/integrations/tests/add-integration.databricks.test.ts`:
- Around line 104-136: The test 'creates databricks integration with optional
schema and catalog' is missing verification of the generated env file; update
the test that calls createIntegration({ file: filePath, envFile: envFilePath })
to also read and assert the contents of envFilePath (similar to other tests),
ensuring the token env variable name matches the mocked UUID pattern (mockUUID)
and expected value (e.g., AAAAAAAA_BBBB_CCCC_DDDD_EEEEEEEEEEEE__TOKEN); locate
the test block using identifiers createIntegration, filePath, envFilePath,
mockUUID and add a readFile + expect check for the .env contents after awaiting
promise and before/after asserting yamlContent.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.materialize.test.ts`:
- Around line 190-273: The SSH test "adds SSH fields when SSH is enabled" is
missing an assertion that the .env file still contains the expected secret
(other tests assert .env contents); after awaiting promise (or before/after
reading yamlContent) read the envFilePath and assert its contents include
"MZ_ID_001__PASSWORD=secret-pass" (or the exact expected line including newline)
so the test mirrors the other cases and verifies the environment file was
preserved/updated; reference the test name and the editIntegration call to
locate where to insert the readFile(envFilePath, 'utf-8') + expect(...)
assertion.

---

Duplicate comments:
In
`@packages/cli/src/commands/integrations/tests/edit-integration.mindsdb.test.ts`:
- Around line 48-267: Add new Vitest cases in this test file around the existing
edit-integration.mindsdb.test.ts suite to cover error and edge scenarios: (1) a
test using editIntegration where the user enters an invalid port
(non-numeric/out-of-range) and assert validation/failure behavior; (2) a test
where required fields (e.g., Database or User) are cleared and assert the CLI
prompts/error handling; (3) a test where the .env file is missing or the
ID001__PASSWORD variable is absent and assert password handling/error; (4) a
test that enters special characters/unicode in name/host/database to ensure
correct YAML escaping; and (5) a positive SSL-enabled path that chooses Enable
SSL: (y/N) => y and asserts ssl-related metadata written. Use the same helpers
and symbols from this file (editIntegration, EXISTING_YAML,
filePath/envFilePath/tempDir, screen, promise) so tests integrate with the
existing flow and assertions.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.spanner.test.ts`:
- Around line 42-150: Capture a shallow snapshot of process.env before calling
editIntegration in both tests (the ones that create promise =
editIntegration({...})), then after await promise assert that process.env
matches the snapshot to ensure the edit flow did not mutate global env; update
the two tests in edit-integration.spanner.test.ts to save const envBefore = {
...process.env } immediately before invoking editIntegration and add
expect(process.env).toEqual(envBefore) right after await promise (or use a
deep-equality matcher), keeping references to editIntegration and the promise
variable to locate the change.

In
`@packages/cli/src/commands/integrations/tests/edit-integration.sql-server.test.ts`:
- Around line 14-16: The test stubs getProcessEnv() which can hide dotenv
side-effects and the suite never asserts or restores process.env, risking leaked
env vars when editIntegration runs; after each await of the test promise in
packages/cli/src/commands/integrations/tests/edit-integration.sql-server.test.ts
add an assertion that the potentially loaded env key is not present (for example
expect(process.env.ID001__PASSWORD).toBeUndefined()) and ensure any tests that
modify process.env save/restore the original object (or reset the specific keys)
so editIntegration and getProcessEnv stubbing cannot leak dotenv into
process.env.
- Around line 48-110: Add a new test in the same file that uses editIntegration
(and the existing helpers EXISTING_YAML, tempDir, writeFile, readFile, screen)
to simulate an invalid port input followed by correction and inputs containing
special characters in the integration name and host; drive the interactive
prompts via screen.next()/screen.keypress()/screen.type(), first entering an
invalid port (e.g., "not-a-number") and asserting the validation/error prompt
appears, then correct it to a valid numeric port and continue, set name/host to
values with special characters, finish the flow, and finally assert the
resulting YAML (and .env file) contains the corrected port and the
escaped/sanitized special-character name and host as expected.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@packages/cli/src/commands/integrations/tests/edit-integration.materialize.test.ts`:
- Around line 119-278: Add a new test case alongside the existing ones that uses
editIntegration, EXISTING_YAML, tempDir, screen and envFile to exercise
special-character inputs (e.g., set cluster to a value with symbols like
"prod-cluster!@#" and sshUser to "tunnel$user%") and enable SSH, then assert the
written YAML preserves those exact special characters in metadata.cluster and
metadata.sshUser and that the .env content remains unchanged; mirror the
interaction pattern used in the existing tests (calls to screen.next(),
screen.type(), screen.keypress(), awaiting promise) and add the appropriate
inline snapshot expectations for yamlContent and envContent to lock
serialization and prompt handling for non-alphanumeric input.