Should have some testing to verify functionality before bugfixing or improvements #2

stringbone commented 2024年01月13日 22:51:43 +01:00

There should be some amount of testing to verify that the functionality doesn't change when bugfixes or improvements are made.

• Test the JS things, not the gforth stuff
• Use Jasmine for browser testing
• For testing the accessibility of the webpage, use axe-core

There should be some amount of testing to verify that the functionality doesn't change when bugfixes or improvements are made. * Test the JS things, not the gforth stuff * Use [Jasmine](https://jasmine.github.io/pages/getting_started.html) for browser testing * For testing the accessibility of the webpage, [use axe-core](https://github.com/marcysutton/axe-jasmine-unit/blob/5b1bc5409ddc5c21be940f6b818c16a4f313bb68/README.md)

stringbone commented 2024年01月13日 23:11:29 +01:00

Break out utilities that are not directly touching the main webpage to better test them. Most pieces should be independent of the DOM.

Break out utilities that are not directly touching the main webpage to better test them. Most pieces should be independent of the DOM.

stringbone commented 2024年01月24日 03:36:49 +01:00

One interesting thing here is that if I try to use imports and exports to test utilities in isolation, we get errors by filepath. This is because the current way to navigate and edit files is by way of edit.cgi/<filename>. Because we are using a / and not something else (like a query string with percent encoding, with encodeURIComponent), it considers the filepath as the whole path, including the post edit.cgi part. There is not a way to get JS to recognize in a way that affects the import behavior. So the next step might be to modify it from just slashes as filepaths to a URI situation.

One interesting thing here is that if I try to use imports and exports to test utilities in isolation, we get errors by filepath. This is because the current way to navigate and edit files is by way of `edit.cgi/<filename>`. Because we are using a `/` and not something else (like a query string with percent encoding, with [encodeURIComponent](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent)), it considers the filepath as the _whole path_, including the post `edit.cgi` part. There is not a way to get JS to recognize in a way that affects the import behavior. So the next step might be to modify it from just slashes as filepaths to a URI situation.

stringbone commented 2024年01月24日 03:52:49 +01:00

Ah! I could just remove the trailing filepath in the edit.cgi after it is loaded. WOuld make more sense to signify what file is being edited in some other way anyway, as it should be on the screen while editing and in the browser.

Ah! I could just remove the trailing filepath in the edit.cgi after it is loaded. WOuld make more sense to signify what file is being edited in some other way anyway, as it should be on the screen while editing and in the browser.

stringbone commented 2025年01月26日 23:54:17 +01:00

I think I've done all I can, considering the limitations. Everything else will need to be manual testing.

I think I've done all I can, considering the limitations. Everything else will need to be manual testing.