Closed Zannick closed 1 year ago
Structure of this is going to be macros and functions defined in analyzer
and codegen a test file with all the tests.
It'd be hard to find specific exits that don't exist, except in the case of a specific path. So for the proposed any_path_to
, we'd output all steps from a spot we can access to a spot we can't. (Unfortunately this includes testing warps at every spot.)
Currently we can't simulate having other movement types, but that could be done with a refactoring of local_travel_time
.
After adding many new details to a graph, I've been running the whole program to see if it succeeds at getting to the latest items, but when it doesn't, it takes quite a deal of work to find out why--I've used the visual graph a few times to find places where I've missed edges.
Ideally we would have a better solution for this. In keeping with the codegen, we could write our tests in yaml, at least the ones that are formulaic:
Some ideas for tests:
any_path_to
to check that the given setup can reach the target spotno_path_to
for the oppositecan_obtain
to test collecting an item (at any location available)requires
to test bothany_path_to
andno_path_to
with/without a specific itempath
to check a specific pathThe generated test code should be able to pinpoint where in the graph the expectation fails (which would be different based on the type of test, for example), or at least be more descriptive than simply "panicked because it couldn't reach the objective".