spell-cards.love/Manual_tests.md

200 lines
6.8 KiB
Markdown
Raw Permalink Normal View History

I care a lot about being able to automatically check _any_ property about my
2022-06-15 05:47:49 +00:00
program before it ever runs. However, some things don't have tests yet, either
because I don't know how to test them or because I've been lazy. I'll at least
record those here.
2023-10-22 17:16:41 +00:00
Initializing settings:
2023-03-31 06:17:14 +00:00
- from previous session
- from defaults
2023-11-17 22:31:56 +00:00
- `default_map` absent/present
2022-07-20 15:53:31 +00:00
- run with an untested version of LÖVE. Error message pops up and waits for a key. The app attempts to continue, and doesn't receive the key.
_yet another_ bugfix to the version check X-( When I stopped running the version check before the tests I also stopped initializing Version, which can be used in tests to watch out for font changes across versions. As a result I started seeing a test failure with LÖVE v12. It looks like all manual tests pass now. And we're also printing the warning about version checks before running tests, which can come in handy if a new version ever causes test failures. The only thing that makes me unhappy is the fact that we're calling the version check twice. And oh, the fact that this part around initialization and version management is clearly still immature. I'll capture some desires and fragmentary thought processes around them: * If there's an error, go to the source editor. * But oh, don't go to source editor on some unactionable errors, so we include a new `Current_app` mode for them: * Unsupported version requires an expert. Just muddle through if you can or give a warning someone can send me. * A failing test might be spurious depending on the platform and font rendering scheme. So again just provide a warning someone can send me. [Source editor can be confusing for errors. Also an editor! But not showing the file you asked for!] * But our framework clears the warning after running tests: * If someone is deep in developing a new feature and quits -> restore back in the source editor. [Perhaps `Current_app` is the wrong place for this third hacky mode, since we actually want to continue running. Perhaps it's orthogonal to `Current_app`.] [Ideally I wouldn't run the tests after the version check. I'd pause, wait for a key and then resume tests? "Muddle through" is a pain to orchestrate.] * We store `Current_app` in settings. But we don't really intend to persist a `Current_app` of 'error'. Only the main app or 'source' editor. [Another vote against storing 'error' in `Current_app`.] * So we need to rerun the version check after running tests to actually show the warning. [Perhaps I need to separate out the side-effect of setting `Version` from the side-effect of changing `Current_app`. But that's not right either, because I do still want to raise an error message if the version check fails before running tests. Which brings us back to wanting to run the tests after raising the version check..] One good thing: none of the bugs so far have been about silently ignoring test failures. I thought that might be the case for a bit, which was unnerving. I grew similar muddiness in Mu's bootstrap system over time, with several surrounding modes around the core program that interacted poorly or at least unsatisfyingly with each other. On one level it just feels like this outer layer reflects muddy constraints in the real world. But perhaps there's some skill I still need to learn here.. Why am I even displaying this error if we're going to try to muddle through anyway? In (vain) hopes that someone will send me that information. It's not terribly actionable even to me. But it's really intended for when making changes. If a test fails then, you want to know. The code would be cleaner if I just threw an unrecoverable error from the version check. Historically, the way I arrived at this solution was: * I used the default love.errorhandler for a while * I added xpcall and error recovery, but now I have situations where I would rather fall back on love.errorhandler. How to tell xpcall that? But no, this whole line of thought is wrong. LÖVE has a precedent for trying to muddle through on an unexpected version. And spurious test failures don't merit a hard crash. There's some irreducible requirement here. No point making the code simplistic when the world is complex. Perhaps I should stop caching Version and just recompute it each time. It's only used once so far, hardly seems worth the global. We have two bits of irreducible complexity here: * If tests fail it might be a real failure, or it might not. * Even if it's an unexpected version, everything might be fine. And the major remaining problem happens at the intersection of these two bits. What if we get an unexpected version with some difference that causes tests to fail? But this is a hypothetical and not worth thinking about since I'll update the app fairly quickly in response to new versions.
2023-12-07 01:34:04 +00:00
- run with a LÖVE v12 release candidate. No errors; it is a supported version. All tests pass.
- create a couple of spuriously failing tests. Run with an untested version of LÖVE. Error message includes message about untested version.
2023-12-03 20:11:17 +00:00
Code loading:
* run love with directory; text editor runs
* run love with zip file; text editor runs
2022-07-20 15:53:31 +00:00
* How the screen looks. Our tests use a level of indirection to check text and
graphics printed to screen, but not the precise pixels they translate to.
- where exactly the cursor is drawn to highlight a given character
- analogously, how a shape precisely looks as you draw it
### Protocol with driver; error-handling
* clone this repo to a new client app, clear its save dir[1], run it, run the
driver, add a definition:
```
on.draw = function()
end
```
Hit F4. No error.
Quit driver, quit client app. Restart client app. No error.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, add a definition that draws to screen:
```
on.draw = function()
love.graphics.print('hello!', 50,50)
end
```
Hit F4. Client app shows 'hello!'
Quit driver, quit client app. Restart client app. No error. Client app shows 'hello!'
* clone this repo to a new client app, clear its save dir, run it, run the
driver, add a definition containing invalid Lua:
```
on.draw = function(
```
Hit F4. Driver shows an error under the definition.
Fix the definition:
```
on.draw = function()
end
```
Hit F4. The error disappears.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, add a definition containing invalid Lua:
```
on.draw = function(
```
Hit F4. Driver shows an error under the definition as before.
Quit the client app.
Restart the client app. It loads up without error.
Switch back to the driver. Fix the definition.
```
on.draw = function()
end
```
Hit F4. The error disappears.
Driver can connect to app on errors in on.initialize (and `on.load_settings`).
fix initialization errors using driver.love Changes inside on.initialize are minefields. Until now, if you made a mistake when modifying on.initialize, you could end up in a situation where the app would fail irrecoverably on the next startup. You'd have to go dig up a text editor to fix it. After this commit, errors in on.initialize wait for commands from driver.love just like any other error. Recovering from errors during initialization is a little different than normal. I don't know how much of initialization completed successfully, so I redo all of it. I think this should be safe; the sorts of things we want to do on startup tend to be idempotent just like the sorts of things we do within an event loop with our existing error handling. Things are still not ideal. Initialization by definition happens only when the app starts up. When you make changes to it, you won't find out about errors until you restart the app[1], which can be much later and a big context switch. But at least you'll be able to fix it in the usual way. Slightly more seamless[2]. One glitch to note: at least on Linux, an app with an initialization error feels "sticky". I can't seem to switch focus away from it using Alt-tab. Hitting F4 on the driver also jarringly brings the client app back in focus when there was an initialization error. But the mouse does work consistently. This feels similar to the issues I find when an app goes unresponsive sometimes. The window manager really wants me to respond to the dialog that it's unresponsive. Still, feels like an improvement. [1] I really need to provide that driver command to restart the app! But there's no room in the menus! I really need a first-class command palette like pensieve.love has! [2] https://lobste.rs/s/idi1wt/open_source_vs_ux
2023-11-17 16:31:41 +00:00
* clone this repo to a new client app, clear its save dir, run it, run the
driver, define `on.initialize` with a run-time error:
fix initialization errors using driver.love Changes inside on.initialize are minefields. Until now, if you made a mistake when modifying on.initialize, you could end up in a situation where the app would fail irrecoverably on the next startup. You'd have to go dig up a text editor to fix it. After this commit, errors in on.initialize wait for commands from driver.love just like any other error. Recovering from errors during initialization is a little different than normal. I don't know how much of initialization completed successfully, so I redo all of it. I think this should be safe; the sorts of things we want to do on startup tend to be idempotent just like the sorts of things we do within an event loop with our existing error handling. Things are still not ideal. Initialization by definition happens only when the app starts up. When you make changes to it, you won't find out about errors until you restart the app[1], which can be much later and a big context switch. But at least you'll be able to fix it in the usual way. Slightly more seamless[2]. One glitch to note: at least on Linux, an app with an initialization error feels "sticky". I can't seem to switch focus away from it using Alt-tab. Hitting F4 on the driver also jarringly brings the client app back in focus when there was an initialization error. But the mouse does work consistently. This feels similar to the issues I find when an app goes unresponsive sometimes. The window manager really wants me to respond to the dialog that it's unresponsive. Still, feels like an improvement. [1] I really need to provide that driver command to restart the app! But there's no room in the menus! I really need a first-class command palette like pensieve.love has! [2] https://lobste.rs/s/idi1wt/open_source_vs_ux
2023-11-17 16:31:41 +00:00
```
on.initialize = function()
foo = bar+1
end
```
Hit F4.
Quit the client app and restart. App shows an error.
Edit `on.initialize` in the driver and remove the error:
```
on.initialize = function()
end
```
Hit F4. The error disappears from the app and driver.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, define `on.initialize` with a run-time error:
fix initialization errors using driver.love Changes inside on.initialize are minefields. Until now, if you made a mistake when modifying on.initialize, you could end up in a situation where the app would fail irrecoverably on the next startup. You'd have to go dig up a text editor to fix it. After this commit, errors in on.initialize wait for commands from driver.love just like any other error. Recovering from errors during initialization is a little different than normal. I don't know how much of initialization completed successfully, so I redo all of it. I think this should be safe; the sorts of things we want to do on startup tend to be idempotent just like the sorts of things we do within an event loop with our existing error handling. Things are still not ideal. Initialization by definition happens only when the app starts up. When you make changes to it, you won't find out about errors until you restart the app[1], which can be much later and a big context switch. But at least you'll be able to fix it in the usual way. Slightly more seamless[2]. One glitch to note: at least on Linux, an app with an initialization error feels "sticky". I can't seem to switch focus away from it using Alt-tab. Hitting F4 on the driver also jarringly brings the client app back in focus when there was an initialization error. But the mouse does work consistently. This feels similar to the issues I find when an app goes unresponsive sometimes. The window manager really wants me to respond to the dialog that it's unresponsive. Still, feels like an improvement. [1] I really need to provide that driver command to restart the app! But there's no room in the menus! I really need a first-class command palette like pensieve.love has! [2] https://lobste.rs/s/idi1wt/open_source_vs_ux
2023-11-17 16:31:41 +00:00
```
on.initialize = function()
foo = bar+1
end
```
Hit F4.
Quit the client app and restart. App shows an error.
Hit F4 again in the driver (without fixing the error).
The client app continues to show the error.
Driver can connect to app on errors in `on.quit` (and `on.save_settings`).
* clone this repo to a new client app, clear its save dir, run it, run the
driver, define `on.quit` with a run-time error:
```
on.quit = function()
foo = bar+1
end
```
Hit F4.
Try to quit the client app. It shows an error and refuses to quit.
Edit `on.quit` in the driver and remove the error:
```
on.quit = function()
end
```
Hit F4. The error disappears from the app and driver.
Try to quit the client app. Now the quit succeeds.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, define `on.quit` with a run-time error:
```
on.quit = function()
foo = bar+1
end
```
Hit F4.
Try to quit the client app. It shows an error and refuses to quit.
Hit F4 again in the driver (without fixing the error).
Try to quit the client app again. It continues to show the error.
Driver can connect to app that contains test failures on startup.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, define a new test with an invalid assertion:
```
test_foo = function()
check(nil, 'foo')
end
```
Hit F4. The test fails.
Quit the client app and restart. App shows an error.
Edit `test_foo` in the driver and remove the error:
```
test_foo = function()
end
```
Hit F4. The error disappears from the app and driver.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, define a new test with an invalid assertion:
```
test_foo = function()
check(nil, 'foo')
end
```
Hit F4.
Quit the client app and restart. App shows an error.
Hit F4 again in the driver (without fixing the error).
The client app continues to show the error.
* clone this repo to a new client app, clear its save dir, run it, run the
driver, add a definition containing invalid Lua:
```
on.draw = function(
```
Hit F4. Driver shows an error under the definition as before.
Quit the client app.
Switch back to the driver. Hit F4. The driver hangs and needs to be
force-quit. [This is not ideal, but how things are today.]
[1] We never clear the app from the driver's config. driver.love needs to be
robust to apps changing out from under it.
2022-07-20 15:53:31 +00:00
### Other compromises
Lua is dynamically typed. Tests can't patch over lack of type-checking.
* All strings are UTF-8. Bytes within them are not characters. I try to label
2022-06-20 15:24:56 +00:00
byte offsets with the suffix `_offset`, and character positions as `_pos`.
For example, `string.sub` should never use a `_pos`, only an `_offset`.
* Some ADT/interface support would be helpful in keeping per-line state in
2023-10-28 06:57:18 +00:00
sync. Any change to line data should clear the derived line property
`screen_line_starting_pos`.
* Some inputs get processed in love.textinput and some in love.keypressed.
Several bugs have arisen due to destructive interference between the two for
some key chord. I wish I could guarantee that the two sets are disjoint. But
perhaps I'm not thinking about this right.
* Like any high-level language, it's easy to accidentally alias two non-scalar
variables. I wish there was a way to require copy when assigning.
2023-03-29 05:00:43 +00:00
* I wish I could require pixel coordinates to be integers. The editor
defensively converts input margins to integers.
* My test harness automatically runs `test_*` methods -- but only at the
top-level. I wish there was a way to raise warnings if someone defines such
a function inside a dict somewhere.