Registering a test cost four edits across a dozen CMakeLists files: add_test,
add_executable, a conditional add_dependencies on gtest, and target_link_libraries.
The conditional branch was the trap -- it is only needed when GTest was fetched and
add_subdirectory'd, and omitting it yields undefined gtest symbols at link time --
so it was easy to leave out and impossible to notice until the link failed.
Fold all four steps into cockatrice_add_test() and migrate every test directory
onto it, with a cockatrice_add_manual_test() wrapper for the three benchmarks that
are built but deliberately kept out of ctest. The calls now read as a declaration
of what a test is rather than a transcript of how to register one.
While rewriting the registrations, replace add_test(NAME x COMMAND x) with
gtest_discover_tests(). Naming the binary as a single CTest entry meant a CI failure
reported only which binary failed, and ctest -R Suite.Case could not select an
individual case. Discovery raises the suite from 35 opaque entries to 469 real ones:
ctest -R ThemeMigrationTest.IsIdempotent now runs exactly that case, and
ctest -L server / -LE bench work off labels applied at registration.
Give every test a 60s TIMEOUT. CTest's implicit default is 1500s, so one hung
socket wait would stall CI for 25 minutes, and single_instance_manager_test already
does real QLocalSocket waits.
Dropping per-case granularity costs wall-clock time, since the suite becomes
process-spawn bound rather than CPU bound: serial ctest went from 3.8s to 30.8s. Run
it with -j in CI to recover it -- 7.6s at -j4, and 3.5s at -j8, both at or below
the old serial time. The binaries are parallel-safe: the only test claiming a fixed
resource scopes its local socket name to its own pid, so concurrent copies cannot
collide.
Also delete dummy_test, which asserted 1 == 1 and only proved the harness was
wired up -- something the other 468 cases already establish.
No test is added, removed, or changed by this commit; the 469 cases are the same
ones the 35 binaries contained.
* [Client] Add zone management to the deck state manager
State-layer operations for custom deck zones, plus the shared prompt
dialog that later editor menus will call into.
- moveCardToZone relocates every copy of a card row into any zone,
refusing non-card rows and tokens so miswired selections can never
shred a group or turn tokens into deck cards. The current zone is
found by walking ancestors, which also handles legacy top-level
zones.
- createCustomZone, renameCustomZone, moveCustomZone and
removeCustomZone wrap the tree API with memento history, model
rebuilds and deck hash refreshes via modifyTree.
- Same-board zone moves return success without minting a history
entry, keeping the undo log honest.
- promptForNewZone asks for a name and the parent zone, keeps Ok
disabled until the trimmed name passes a caller-supplied validator
(shown inline as an error), and reports its own translation context.
Took 14 minutes
# Commit time for manual adjustment:
# Took 6 minutes
# Commit time for manual adjustment:
# Took 33 seconds
* [DeckEditor] Address zone-management review feedback
- Expose DecklistNodeTree::hasZoneName and use it in validateNewZoneName
so the uniqueness scan covers custom zones on every board, not just the
standard ones.
- Hide the board selector in the rename dialog path where it is not used.
- Emit deckHashChanged after refreshDeckHash so the deck hash label stays
current after zone create/rename/move/remove.
* [DeckEditor] Notify card set changes after zone edits and drop the board scan
- modifyTree emits cardNodesChanged alongside deckHashChanged so the
banner-card combo and printing in-deck counts refresh after removing a
zone that still holds cards
- DecklistNodeTree::findCustomZoneByName is public and moveCustomZone uses
it, locating zones under non-standard boards (e.g. tokens) instead of
scanning only main/side/maybeboard
---------
Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
* [DeckList] Add custom deck zones to the deck tree
Introduce user-definable zones nested under a board zone (main, side
or maybeboard) so players can organize cards inside a board without
changing board semantics.
- addCustomZone, renameCustomZone, moveCustomZone and removeCustomZone
manage zones. Names are unique across the whole deck and the standard
zone names (main/side/maybeboard/tokens) stay reserved.
- Board zones are created lazily on first use.
- getZoneObjFromName resolves custom names to their nested node so
addCard and XML loading route cards into them. Unknown names keep
creating legacy top-level zones.
- deleteNode keeps empty custom zones alive and only prunes empty
board zones.
- New deck_list_zones test suite locks hash parity with flat decks,
sideboard size accounting, maybeboard exclusion from plain export
and native-format round-trips.
Took 17 minutes
Took 11 minutes
* Extract to function
Took 4 minutes
---------
Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
