TST: Increase code coverage to 90%

[Gui-FernandesBR]

For a python library like ours, a 90% coverage threshold should be the ideal.
It should already consider the slow tests as well.

Coverage is not the only metric that matters, but it is the best one.

[Gui-FernandesBR]

As of today, we have a cc of 87% when considering the slow tests.

Unfortunately, when we exclude the slow tests this number reduced to only 76%.

Ideally, given that RocketPy is a library, code coverage should be of 99.9% with slow tests and 90% without the slow tests

[ting-hong-shieh]

I measured the current baseline at cb6106a717207dd8fc2dfe1446d80ff75022f21b before starting the first test-only slice.

Non-slow baseline

The unit, integration, and acceptance suite completed with 2,187 passed, 53 skipped, and three PyVista animation tests deselected. The RocketPy doctest pass then added 48 passing tests.

Metric	Result
Statements	17,080
Covered	13,810
Missed	3,270
Coverage	80.8548%

The three deselected animation tests are the cases that the GitHub workflow already isolates and retries on native SIGBUS/SIGSEGV exits. The first one terminated my local VTK process with a segmentation fault, so I did not include partial results from those tests.

Slow-test contribution

There are 44 slow cases. I completed 43 locally after excluding test_monte_carlo_simulate[True], which stopped making progress in the local multiprocessing run. Of those 43 cases, 42 passed. test_hrrr_atmosphere failed because the live HRRR file ended at 2026-08-14 19:00 UTC while the test requested 2026-08-14 22:59 UTC through its now + 12 hours offset.

Taking the union of executed statements from the clean non-slow run and those 43 slow cases gives:

Metric	Result
Statements	17,080
Covered	15,071
Missed	2,009
Coverage	88.24%

I am treating 88.24% as a measured partial-slow result, not as a complete green slow-suite baseline, because of the HRRR failure and excluded parallel case.

The largest remaining gaps after that union are:

Module	Missed statements
plots/flight_plots.py	413
mathutils/function.py	158
environment/environment.py	149
simulation/monte_carlo.py	98
plots/monte_carlo_plots.py	89
tools.py	77

I opened #1152 as the first small, deterministic slice. It adds six controller behavior tests without changing production code:

Scope	Before	After
control/controller.py	85.71%	100.00%
prints/controller_prints.py	29.17%	91.67%
Entire package, non-slow	80.8548%	80.9953%

I will keep later slices separated by subsystem and prioritize deterministic behavior assertions over network-dependent or render-only execution.

[ting-hong-shieh]

Follow-up: #1153 addresses the HRRR failure from the baseline above. The slow test used naive datetime.now(), which Environment.set_date() interpreted as UTC even when the host was in Asia/Taipei. Using datetime.now(timezone.utc) changed the same live test from an out-of-range 22:58 UTC request to an available 15:00 UTC forecast step; the test then passed in 4.12 seconds.

The local test_monte_carlo_simulate[True] multiprocessing hang remains the only excluded slow case from that measurement.

[Gui-FernandesBR]

@ting-hong-shieh both #1152 and #1153 are already merged onto develop.

The target with this issue is to achieve a 90% test coverage without slow tests. Actually, slow tests should never be needed (but that is another issue...).

Do you think you could propose new PRs increasing test coverage?