Skip to content
This repository was archived by the owner on Sep 11, 2025. It is now read-only.
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions projects/browser-extension-testing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Browser extension testing and reliability
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You intend to work on this immediately after shipping sourcegraph/browser-extensions#271, right? (Do you have an ETA on merging that PR?) That sounds right to me. I already moved the rest of "Better config and depoyment for code host UI integrations" to November 2018 on https://docs.sourcegraph.com/dev/roadmap#november-2018 and split out the options page blog post to #46.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. I just have to pull in access token changes that I made the other day into the new options menu.


Browser extensions are a powerful way to improve your workflow by adding new
features to your browser. However, they are inherently hard to test. Our popular
[browser extension](repo...), which adds code intelligence to your code host,
runs in multiple browsers ([Chrome](...), [Firefox](...)) which can change the
way their APIs work at any time and runs across many code
hosts, any of which could change their DOM, thus breaking our extension.

Reliability is important to us and our users, so we're building up the testing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the requirements for you to feel comfortable enabling Sourcegraph extensions for all (removing the feature flag)? Is your comment sourcegraph/browser-extensions#272 (comment) still current? If so, please explicitly state those conditions/requirements here, because that's the main piece of info the folks working on extensions will want to know from this doc.

infrastructure around our browser extension. Here's how we plan to do it:

1. Abstract code so it is more unit testable

- Keep calls to browser extension APIs out of business logic so we can unit
test that logic
- Rearchitect logic integrating with individual code hosts so that we can unit
test the integration of code hosts and code intelligence

1. Add more e2e tests

- Run each test on all supported code hosts - code hosts won't be considered
fully supported until we're able to run tests on it
- Test with different feature flags enabled or disabled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should remove some features and feature flags while we're at it:

  • ✔️ inline symbol search has proven stable and not to interfere, so remove feature flag and enable by default /cc @ggilmore (I also would like to extend and promote this feature more, and make it so extensions can contribute to it!) <-- if this delays your work on this project, then you can punt
  • ❌ remove GitHub file tree navigation. Some people use this, but it is not the killer feature of our extension. Octotree does it better and does it for private code more easily than us. We also won't be providing this for other code hosts, and I want to minimize the number of features we have that are only for a single code host (it confuses users and makes them feel 2nd-class).
  • ❌ remove the feature "Open a new window with Sourcegraph search results" because users didn't like it
  • keep "Render mermaid.js" diagrams" as a feature flag as is

- Test using different Sourcegraph instances