[patch] Regression tests for elevated ways before refactoring tool_build_way_t

[victor_18993]

Before touching tool_build_way_t, I wanted a proper regression net for elevated ways.

Right now elevated ways have no dedicated tests, so moving that code would mean refactoring without knowing whether the behaviour changed. This patch adds 26 tests and does not touch production code.

The tests cover straight routes, bends, water, roads, stations, slopes, map edges, ownership, scenario rules, maintenance, rebuilding and removal. I measured every expected result on an unmodified build before turning it into an assertion.

A few current behaviours look odd — for example, funds are not checked, a single slope is rejected while a double slope is accepted, and an elevated way can climb over a bridge deck — but this patch deliberately keeps them unchanged. If any of those are bugs, I would rather handle them separately.

Current state:

Code Select Expand

26/26 new tests
232/232 full suite
git diff --check clean
Only tests/all_tests.nut and the new test_way_elevated.nut are changed.

Question for prissi

Prissi, before I move any production code, does this test baseline cover the elevated-way behaviour you want preserved?

For the later separation, my preference is to keep TOOL_BUILD_WAY as the pakset and network entry point and separate the different rules internally. Giving elevated ways a new tool ID would require every pakset to update its menuconf.tab.

Is that the direction you had in mind, or would you prefer elevated ways to become a separate tool despite the pakset compatibility cost?

[prissi]

The maglev tests of pak64 are elevated ways, but I did not look into the tests in detail. I must admit that I never programmed tests until they were submitted.

On the different tools, fill_menu could automatically assign elevated ways a different tool than normal ways. That seems rather easy?

[victor_18993]

Thanks, Prissi.
Yes, if

Code Select Expand

fill_menu() can assign elevated ways a separate tool automatically, that would avoid the pakset compatibility problem I was concerned about. I was assuming that introducing a new tool ID would require existing

Code Select Expand

menuconf.tab files to be updated manually.
I will review the current

Code Select Expand

fill_menu() path and see whether elevated way descriptors can be routed to a separate tool there while keeping the existing pakset definitions unchanged.
If that works cleanly, I agree that separating the elevated-way tool would probably give us a much better boundary for the later refactoring than keeping everything inside

Code Select Expand

tool_build_way_t.
I will keep the current regression patch independent from that work so that the baseline remains unchanged while the production-code split is developed separately.