code-charity
Add testing framework and Initial Tests
I have noticed that there is currently no test coverage in this project. To improve the stability and maintainability of ImprovedTube, I suggest adding a testing framework and some initial tests. This will aid potential contributing developers to notice where the mistakes are and focus on it accordingly. A framework will also provide a platform for future contributors and encourage them to add more tests increasing the coverage.
Proposed Solution: -Add a Testing Framework for Javascript segments (at first): Using tools like MochaJS, Jest or Jasmine -Create a tests folder in the root of the project to store all test files. -Add Initial Tests on some features
Steps to Reproduce:
- Integrate the framework into the project by installing it via npm/yarn.
- Create the tests folder.
- Add initial test cases for core functionalities.
- Run the tests
Should I start on this issue? Do you have any preferences for the framework?
hi! @PTheocharis welcome back! And thank you!
Sounds good, just adding context:
We can chose tools by most code (/ best features / most dev activity),
(next to ease of use and what you used before, in case you want to dedicate time regularly.)
We can start with making github automatically check syntax typos at every commit.
[ ] Automated uploads by Github actions( Chrome & FireFox & Edge Chrome Web Store Safari Opera Whale )
(or Store's APIs: Chrome & FireFox & Microsoft Edge Store Safari Opera Whale)
- [ ] Building for the Browser's Stores : https://github.com/code-for-charity/YouTube-Extension/tree/master/py
[ ] Automated tests by Github Actions? or Selenium or... ( Possibly different rounds, with popular settings or everything & performance. Which could periodically run on the master branch or after every PR and commit)
( from 2021 https://github.com/code-charity/youtube/issues/842#issue-838847298 )
Some issues could be easier to prevent than test (Many features might be written once and for all others require change after youtube DOM updates, some of which we could predict by wider CSS selectors or making the extension itself run an analysis of the DOM every now and then to notice some changes. Or we could at least base all of these features on a rule set like this: https://github.com/gijsdev/ublock-hide-yt-shorts/blob/master/list.txt (- and such rule-set can be loaded into an extension from a github repo without updating the stores. compare: https://github.com/darkreader/darkreader/tree/main/src/config) )
To clarify: Do you want me to start my suggested plan with Jest for example, take up issue #842 or both?
you chose! all options sound good.
I might just be consolidating issue threads (842 could be closed maybe)
Looking forward to teamwork and run integrations and automations (only one yet: https://github.com/code-charity/youtube/blob/master/.github/workflows/build-safari-app.yml thanks to @dodieboy
and @unnamed-orbert was syncing with @crowdin (just gave up on that currently ) )
Even something as basic as Github Action to validate js and run it thru JSLint on every push would be great.
I have already placed Jest as a framework and placed some initial indicative tests. I will try to add JSlint now.
BTW, imagine we had to run many routines, like JSLint on every commit in all Repos from 10 to 10000 Stars.
How would we find everything on the list, and prioritize it to remain universal?
(compare "Wikipedia's many bots" https://github.com/code-charity/Bulk-Contributor)
yay github action linter, nice! Did I say JSLint? I meant ESLint, sorry :( JSLint author has this weird notion everyone should format code like he does and everything else is prohibited (Tabs). There is https://github.com/marketplace/actions/run-eslint but I dont know where you configure rules for the linter.
/*eslint indent: ["error", "tab"]*/
btw current JSLint just fails to parse our codebase and errors out at 4%, but the test still reports pass, so it should not be relied upon at all until fixed