News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

[patch] Regression tests for elevated ways before refactoring tool_build_way_t

Started by victor_18993, Today at 01:40:01 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

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:

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?
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)