Skip to content

test: fix pre-existing unit-test failures (green the suite) - #100

Draft
07souravkunda wants to merge 1 commit into
masterfrom
chore/green-unit-tests
Draft

test: fix pre-existing unit-test failures (green the suite)#100
07souravkunda wants to merge 1 commit into
masterfrom
chore/green-unit-tests

Conversation

@07souravkunda

Copy link
Copy Markdown
Collaborator

What was failing

On a clean checkout of master, mvn -q -B test reported 2 errors out of 14 tests:

  • testIsRunning
  • testMultipleBinary

Both threw a NullPointerException from ProcessBuilder.start() (via Local.runCommand) whenever BROWSERSTACK_ACCESS_KEY was not set in the environment. These two tests start a real BrowserStack Local tunnel, so the access key is read from the environment and appended to the binary command. With no key, a null element lands in the command list and ProcessBuilder.start() rejects it — the failure happens before any assertion runs. The other 12 tests only build the command string (onlyCommand=true) and pass regardless.

This means every clean run without credentials (local dev, forks, CI without secrets) starts red, forcing anyone touching the repo to first confirm the failures pre-date their change.

What this fixes

testIsRunning and testMultipleBinary are integration tests that genuinely require credentials. Guarded each with a JUnit assumeNotNull(System.getenv("BROWSERSTACK_ACCESS_KEY")) so they skip gracefully when no key is present, while still running the full assertions whenever a key is available (e.g. CI with secrets). No assertion is weakened, disabled, or removed. Scope is limited to the test file.

Verified with BROWSERSTACK_ACCESS_KEY set: testIsRunning runs and passes end-to-end (real tunnel up → isRunning() true).

What is left red

Nothing masks a product bug.

One note for maintainers: when a valid key is present, testMultipleBinary can still fail intermittently at its first start() with "Either another browserstack local client is running ... port 45691". This is a test-isolation issue — the tunnel from the preceding testIsRunning has not released the fixed default port before this test opens its own on the same port. It is a harness-ordering problem, not a product defect (the binary correctly refuses a duplicate tunnel), and it is out of scope for this credential-less baseline fix. A follow-up could isolate the live tests with unique local identifiers / port cleanup.

How to run the suite

mvn -q -B test
  • Without BROWSERSTACK_ACCESS_KEY: 12 tests run, the 2 live tunnel tests are skipped → green.
  • With a valid BROWSERSTACK_ACCESS_KEY exported: the live tests execute against a real tunnel.

The two live-tunnel tests (testIsRunning, testMultipleBinary) failed on a
clean checkout with a NullPointerException whenever BROWSERSTACK_ACCESS_KEY
was not set: the null key was appended to the process command and
ProcessBuilder.start() rejected it.

These are integration tests that start a real BrowserStack Local tunnel and
genuinely require credentials. Guard them with a JUnit assumeNotNull on the
access key so they skip gracefully when no key is present (local/fork/CI
without secrets) while still running the full assertions whenever a key is
available. No assertion is weakened or removed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant