Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide and implement unit testing framework #159

Closed
melink14 opened this issue Sep 15, 2019 · 12 comments · Fixed by #561
Closed

Decide and implement unit testing framework #159

melink14 opened this issue Sep 15, 2019 · 12 comments · Fixed by #561
Assignees
Labels
Code health Issues which if fixed would improve the health of the project (as opposed to new features/bugs) released testing Related to testing code

Comments

@melink14
Copy link
Owner

Probably use Jasmine with karma?

At first should add test harness and a couple of tests as proof of concept.

(maybe add some incremental coverage measurements)

@melink14 melink14 added the Code health Issues which if fixed would improve the health of the project (as opposed to new features/bugs) label Sep 15, 2019
@melink14
Copy link
Owner Author

codecov.io free for open source
https://codecov.io/

@melink14
Copy link
Owner Author

melink14 commented Aug 6, 2020

Browserstack for running on browsers in the cloud and some extension tips:
https://www.browserstack.com/guide/test-chrome-extensions-in-selenium

@melink14
Copy link
Owner Author

melink14 commented Aug 6, 2020

@melink14
Copy link
Owner Author

melink14 commented Aug 6, 2020

@melink14
Copy link
Owner Author

https://github.com/microsoft/tsyringe

Especially for testing with modules, we may want dependency injection for easier stubbing.

@melink14
Copy link
Owner Author

@melink14 melink14 self-assigned this Jun 28, 2021
@melink14
Copy link
Owner Author

Started working on this for #366 since it should have a test.

Currently using a karma + jasmine with headless chrome as per #159 (comment) minus mocha

For typescript, I had tried karma-typescript plugin but it didn't work with es6 well so instead I switched to using karma-webpack since I already use that for production.

As part of this, I also ended up making a separate tsconfig for ts-node so that I could have advanced es6 enabled for my code and use legacy modules for node TS files (configs and update-db). I'll probably split that part out since I don't think it's related to getting testing working. It will be useful if it allows me to use top level awaits though!

In my attempts to get a idiomatic setup and everything working I took a circuitous path but the following resources were most helpful:

  • https://developerlife.com/2019/07/06/starter-project-typescript-karma-jasmine-webpack/ had good tips on sharing webpack config though it wasn't enough to get line numbers or debugging working.
  • https://github.com/Janne252/karma-webpack-typescript-coverage-vscode-debug covers my usecase 100% and the launch.json was especially nice for getting vscode debugging working. There's a recent bug that I had to debug myself but the advice here was great.
  • I couldn't get chrome.* APIs to load early enough for the longest time until I found a karma plugin that did it. I ended up using somebody's fork with recent updates but will probably fork it myself for more control given it still has some out of date packages. Maybe I'll publish it for others if I think it's helpful. I still haven't tried to use the stubs so I could run into problems later.
  • I like using Typescript configuration files (autocomplete!) and karma allows that but it's default types don't allow plugin configuration (for webpack in this case). I got it working with a combination of a helpful related gist and general Googling on how to use Omit to replace an interface property with a more general version.
  • Linking to Window's chrome binary didn't work well, it was slow and unstable. I ended up installing chrome into WSL directly after reading some SO posts or github issues. (Example)

Things seem to work as well as I could expect now for unit testing though I still need to write a real working test.

Other things to come later is full integration test as well as code coverage via something like codecov.io or just native karma coverage plugin (combined with github action etc)

@melink14
Copy link
Owner Author

melink14 commented Jun 29, 2021

Update:

This style guide for jasmine is pretty good except for the examples moving setup into beforeEach. Though if the describes are short maybe it would be interesting.

I decided to not use the sinon chrome stuff since the jasmine integration didn't work well. Instead, I made my own chrome fake with Jasmine spys for the functions. It can be easily expanded as tests are added.

@melink14 melink14 added this to the September 2020 milestone Jun 29, 2021
@melink14 melink14 changed the title Add testing framework so new code can be easily tested Decide and implement unit testing framework Jun 29, 2021
@melink14 melink14 added the testing Related to testing code label Jun 29, 2021
@melink14
Copy link
Owner Author

melink14 commented Jul 2, 2021

Updates:

I added a spy reset method to my fake chrome since otherwise it just accumulates method call recordings.

It seems I didn't need any specific sourcemap stuff in my launch.json for some reason. Perhaps due to inline source maps?

I feel like I don't need webpack since I can use ES modules directly but I'd need something to extract the node deps like lit into something that can be used easily! Maybe snowpack can be looked at again now that I'm a bit more knowledable.

melink14 added a commit that referenced this issue Jul 2, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: Jasmine + Karma + Headless Chrome.
Works with vscode debugging for fast test driven development.

Unrelated changes required for compilation:
- options.ts my LitToast interface needed to extend `Element` when
  compiling with karma and tsc. Not sure why it worked with `ts-loader`
- I needed to update webpack.config to accept a partial argv since of
  course we are only using `mode`.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 2, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: Jasmine + Karma + Headless Chrome.
Works with vscode debugging for fast test driven development.

Unrelated changes required for compilation:
- options.ts my LitToast interface needed to extend `Element` when
  compiling with karma and tsc. Not sure why it worked with `ts-loader`
- I needed to update webpack.config to accept a partial argv since of
  course we are only using `mode`.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 2, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: Jasmine + Karma + Headless Chrome.
Works with vscode debugging for fast test driven development.

Unrelated changes required for compilation:
- options.ts my LitToast interface needed to extend `Element` when
  compiling with karma and tsc. Not sure why it worked with `ts-loader`
- I needed to update webpack.config to accept a partial argv since of
  course we are only using `mode`.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 7, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 7, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 7, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

Fixes #366
Fixes #159
@melink14
Copy link
Owner Author

melink14 commented Jul 7, 2021

After doing all of this I decided to try out snowpack for the build tool and it worked better than expected and then I followed that thread to get a matching test setup as well since it's always better for tests to match production as much as possible.

The recommended test runner is @web/test-runner which is new but also built for modern web. I came across some problems trying to use it:

  • Default chrome launcher didn't work. Required --disable-gpu for some reason.
  • content-scripts can't be modules easily and so my test only export in rikaicontent broke when importing to chrome. I fixed this with snowpack-plugin-replace deleting that line in prod configuration.
  • It took a few attempts to get the test runner to find my tests due to how my snowpack was configured. It turned out I needed a custom snowpack mount, mapping extension directory to the root of my output directory.
  • It had no good spec test result reporter so I embedded one from the relevant github issue.

On the other hand after that most things worked directly:

  • vscode debugger connected and was able to work with test runner using some launch config after turning on snowpack sourcemap option.
  • @web/test-runner works best with mocha/chai so I migrated my tests to that but tests themselves were almost identical.
  • chai easily works with sinon so I switched to using sinon-chrome directly and removed my custom chrome fakes.
  • In order to install fake chrome earlier, the setup was to use a custom HTML fragment as opposed to karma's file config but its more explcit and worked out of the box.

The final result is a fast test and useful test runner.

@melink14
Copy link
Owner Author

melink14 commented Jul 7, 2021

Future ideas:

Create medium sized unit tests by using connecting content script to background scripts with custom sendMessage fake.

melink14 added a commit that referenced this issue Jul 7, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 7, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 11, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

With --coverage flag, we get a coverage report that we can upload to
codecov.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 16, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

With --coverage flag, we get a coverage report that we can upload to
codecov.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 16, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

With --coverage flag, we get a coverage report that we can upload to
codecov.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 16, 2021
Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

With --coverage flag, we get a coverage report that we can upload to
codecov.

Fixes #366
Fixes #159
melink14 added a commit that referenced this issue Jul 16, 2021
…use (#561)

Specifically, ignore `display: none` and `visibility: hidden`.

This change is also the first unit tested change so contains the initial
configuration of testing. (See #159 for details on decisions).

Testing Stack: @web/test-runner + Mocha/Chai/Sinon + Puppeteer Headless Chrome.
Works with vscode debugging for fast test driven development.

With --coverage flag, we get a coverage report that we can upload to
codecov.

Fixes #366
Fixes #159
melink14 pushed a commit that referenced this issue Jul 17, 2021
## [2.0.0](v1.2.6...v2.0.0) (2021-07-17)

### ⚠ BREAKING CHANGES

* This version includes optional chaining requiring Chrome >=80

### Features

* Force Google Docs to use HTML mode instead of canvas mode ([#596](#596)) ([94b60a6](94b60a6)), closes [#593](#593)
* **detection:** Ignore invisible nodes when extracting text under mouse ([#561](#561)) ([cb97f36](cb97f36)), closes [#159](#159) [#366](#366) [#159](#159)

### Bug Fixes

* **dict:** Update dictionaries to latest versions. ([#581](#581)) ([77189c3](77189c3))
* Skip text processing when range is null ([#598](#598)) ([ae55bff](ae55bff)), closes [#386](#386)

### Code Refactoring

* Migrate from webpack to snowpack for build step ([#583](#583)) ([1bdd3d3](1bdd3d3))
@melink14
Copy link
Owner Author

🎉 This issue has been resolved in version 2.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code health Issues which if fixed would improve the health of the project (as opposed to new features/bugs) released testing Related to testing code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant