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.

Sign up for GitHub

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

Jump to bottom

syntax highlighter chokes on line starting with ") ====" but compiler understands it... #997

Open
increpare opened this issue Apr 26, 2024 · 3 comments
Open

syntax highlighter chokes on line starting with ") ====" but compiler understands it... #997

increpare opened this issue Apr 26, 2024 · 3 comments

Comments

@increpare
Copy link
Owner

Bildschirmfoto 2024-04-27 um 01 26 17

not sure what the desired behaviour is - doing nothing seems good enough more or less, but some message might be good 😅
@david-pfx
Copy link

david-pfx commented Apr 27, 2024 via email

@increpare
Copy link
Owner Author

Assuming you're talking about the other small bug-fixes from yesterday? Tests only cover core compiler/engine behaviour. Anything beyond (interface bugs, networking) that gets hairy very fast. Let's look at the last four code fixes.

#932 would be awkward to write a test for - download a page then load it, then check that the right tag is being displayed. There is a mild risk of regression, in case I ever add back this compiler optimisation by accident.

#996 doesn't deal exactly with DOM behaviour, but rather handwritten interface code. Uh, it would be rather awkward to write code to produce this behaviour automatically, and also to detect that the correct behaviour is being observed (though maybe I could use a proxy like adding a debug message). Low risk of regression.

#988 is browser-specific. I could write a check that the link is generated with the correct 'download' attribute, but testing that the download works would be awkward because it's very browser-specific. Low change of accidentally breaking it.

#995 could be tested in a browser with input simulation and then inspecting javascript variables afterwards. That's probably the most amenable to browser-DOM testing. A low risk of regression, I'd say.

The game engine is complex and it's very easy to break things accidentally when fixing other things (regressions would definitely happen regularly when fixing compiler bugs if I didn't have a test suite). The things mentioned above, while they could break (and while I do occasionally break things), just don't carry the same risk. Also, making tests for the engine/compiler is very easy, and writing tests for each the above would be much more involved (and they would be likely much more fragile).

@david-pfx
Copy link

All I can really say is it's a shame. The one thing a long-lived product like PS really deserves is a comprehensive test suite that nails its specified behaviour and can be used to check for bugs and regressions. SQLite is my go-to example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@increpare @david-pfx