about summary refs log tree commit diff stats
path: root/Manual_tests.md
Commit message (Collapse)AuthorAgeFilesLines
* Merge lines.loveKartik K. Agaram2023-12-071-3/+3
|\
| * minor tweaks to manual tests while pushing to all forksKartik K. Agaram2023-12-071-3/+3
| |
* | Merge lines.loveKartik K. Agaram2023-12-061-2/+4
|\|
| * redo version checks yet againKartik K. Agaram2023-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm starting to feel better after replacing 1 line with 20 and 2 new bits of global state. I'm now handling two scenarios more explicitly: * If I change Current_app within key_press, the corresponding text_input and key_release events go to the new app. If it's an editor it might insert the key, which is undesirable. Putting such handlers in key_release now feels overly clever, particularly since it took me forever to realize why I was getting stuck in an infinite loop. * Both 'run' and 'source' can hit the version check, so we need to be able to transition from the 'error' app to either. Which necessitates yet another global bit of state: Next_app.
| * redo version checksKartik K. Agaram2023-12-061-2/+3
| | | | | | | | This is still ugly, but hopefully easier to follow.
| * _yet another_ bugfix to the version check X-(Kartik K. Agaram2023-12-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge lines.loveKartik K. Agaram2023-12-031-0/+3
|\|
| * yet another bugfix to the version checkKartik K. Agaram2023-12-031-0/+1
| | | | | | | | | | We could now get test failures before the version check, which might be confusing.
| * bugfix: version checkKartik K. Agaram2023-12-031-0/+2
| |
* | Merge lines.loveKartik K. Agaram2023-10-281-1/+1
|\|
| * remove stale variable from docsKartik K. Agaram2023-10-271-1/+1
| |
* | Merge lines.loveKartik K. Agaram2023-06-081-1/+3
|\|
| * reconcile manual tests with some downstream forksKartik K. Agaram2023-06-081-1/+3
| |
* | Merge lines.loveKartik K. Agaram2023-06-081-0/+4
|\|
| * several bugfixes in saving/loading cursor positionKartik K. Agaram2023-06-081-0/+4
| |
* | Merge lines.loveKartik K. Agaram2023-05-061-2/+1
|\|
| * bugfix: never use utf8 pos in string.subKartik K. Agaram2023-05-061-2/+1
| | | | | | | | | | | | This is a violation of an existing rule in Manual_tests.md. The following command weakly suggests there aren't any others: grep ':sub(' *.lua |grep pos
| * .Kartik K. Agaram2023-03-301-1/+0
| |
* | Merge lines.loveKartik K. Agaram2023-03-301-11/+8
|\|
| * obsolete manual testKartik K. Agaram2023-03-301-4/+0
| |
| * better formattingKartik K. Agaram2023-03-281-9/+11
| |
* | Merge lines.loveKartik K. Agaram2022-12-231-0/+3
|\|
| * require editor margins to be intsKartik K. Agaram2022-12-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Not directly relevant here, but forks of this project that permit zooming can run into weird glitches if margins are not a whole number of pixels. I'd always assumed a type system that divided ints into floats was strictly superior, but now I have experienced a situation where requiring ints isn't just a compromise for the underlying CPU implementation. Particularly since Lua's print() silently hides really tiny fractions.
| * editing source code from within the appKartik K. Agaram2022-09-031-5/+16
| | | | | | | | | | integrated from pong.love via text.love: https://merveilles.town/@akkartik/108933336531898243
* | editing source code from within the appKartik K. Agaram2022-09-031-5/+16
|/ | | | integrated from pong.love: https://merveilles.town/@akkartik/108933336531898243
* bugfix: imprecision in drawingKartik K. Agaram2022-08-031-0/+1
| | | | | | | | | | | scenario: slowly press down mouse button and drag to draw a line release mouse button Before this commit the point would jump just a little bit on release, and points would go slightly to the left of where I expect. Yet another thing it's hard to write an automated test for.
* bugfix: where cursor is drawnKartik K. Agaram2022-07-201-0/+4
| | | | | | | The published version of lines.love was broken for almost an hour. The cursor would render one position to the right of where it really is. To fix it, this commit rolls back 26ba6e4e5a71. There doesn't seem a good way to test it.
* reorg manual tests docKartik K. Agaram2022-07-201-9/+7
|
* experiment: new edit namespaceKartik K. Agaram2022-07-111-0/+4
| | | | | | | | Still lots to do, but the eventual hope is that this will make this project's code easier to reuse from other LÖVE projects. One gotcha: even as we start putting code more aggressively into nested tables, tests must remain at the top-level. Otherwise they won't run.
* ugh, handle absolute as well as relative pathsKartik K. Agaram2022-07-011-0/+8
|
* bugfix: manage screen_top and cursor when resizingKartik K. Agaram2022-07-011-0/+3
|
* record one more case I can't automatically detectKartik K. Agaram2022-06-231-0/+5
|
* bugfixKartik K. Agaram2022-06-211-0/+4
| | | | | State changes when inserting return are now in sync with other characters.
* clearer copyKartik K. Agaram2022-06-201-2/+3
|
* drop last couple of manual testsKartik K. Agaram2022-06-171-12/+0
|
* manual test for adjusting line widthKartik K. Agaram2022-06-171-0/+6
|
* .Kartik K. Agaram2022-06-171-1/+1
|
* .Kartik K. Agaram2022-06-141-3/+3
|
* all pending manual tests done!Kartik K. Agaram2022-06-141-5/+3
|
* test: undo moving pointKartik K. Agaram2022-06-141-1/+0
|
* test: undo naming a pointKartik K. Agaram2022-06-141-1/+0
| | | | Also ensure we autosave.
* test: autosave after name/move/delete of pointKartik K. Agaram2022-06-141-3/+0
|
* test: autosave after any shapeKartik K. Agaram2022-06-141-1/+0
|
* test: moving a pointKartik K. Agaram2022-06-141-3/+0
| | | | | I found some code in the process that seems unreachable. Some chance of a regression here..
* test: naming a pointKartik K. Agaram2022-06-141-1/+0
|
* a little more prose describing manual_testsKartik K. Agaram2022-06-141-0/+30