Skip to content

Write request integration non-browser spec

Chad Woolley requested to merge caw-rd-non-browser-request-integration-spec into master

What does this MR do and why?

Adds a non-browser (non-Capybara) request integration spec for the Remote Development workspaces feature.

  • Currently, the only spec which exercises the full stack from the API all the way down is the ee/spec/features/remote_development/workspaces_spec.rb feature spec.
  • But ee/spec/features/remote_development/workspaces_spec.rb is a browser/capybara spec, which means it's very slow (minimum of 30-40 seconds for every run, even on a fast machine).
  • It is also harder to debug browser-based specs, because the spec and server are running in separate processes.
  • So, this MR adds ee/spec/requests/remote_development/integration_spec.rb, a rails/rspec request integration spec which does the same sort of full-stack end-to-end happy-path integration test as ee/spec/features/remote_development/workspaces_spec.rb
  • This spec runs in under 10 seconds (usually 7-9 seconds) under spring, and is all in the same process, so debugging with breakpoints in both the spec and code is easy. I often use RubyMine conditional breakpoints, where a breakpoint in a low-stack-level common code path executed many times only enables itself once a higher-stack-level breakpoint in the spec is hit.

The motivation behind this was due to starting a large refactor of the Remote Development service layer, and realizing the slow, painful Capybara feature test was the only way to have local TDD and test coverage while doing this refactor.

Other changes

  • Refactors out common logic to a new helper which is shared between the two tests
  • Fixes a bug in spec/support/shared_contexts/json_response_shared_context.rb where it was incorrectly memoizing/caching response values in request specs

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

Make sure all modified tests pass locally with no reductions in coverage.

Merge request reports