Add new Tcl and C++ test cases

[openroad-ci]

Summary

• Adds comprehensive C++ and Tcl regression test suites across all 12 STA modules — 6,159 tests, 100% pass rate
• Strengthens all C++ assertions with meaningful checks, removes empty test bodies
• Adapts all tests to the upstream rel_3.0 API (Corner → Scene/Mode, enum class changes, command renames, etc.)

Test Coverage by Module

Module	C++ Tests	Tcl Tests	Total
search	1,788	74	1,862
liberty	1,005	38	1,043
sdc	870	40	910
network	577	26	603
dcalc	383	—	383
util	317	9	326
verilog	278	41	319
parasitics	199	17	216
spice	126	9	135
sdf	115	10	125
graph	100	11	111
power	96	8	104
test	—	22	22
Total	5,854	305	6,159

C++ Tests (GTest)

• Covers delay calculation, graph construction, liberty parsing, network traversal, parasitics reduction, power analysis, SDC constraints, timing search, utility functions, and Verilog I/O
• Each module has dedicated test fixtures with realistic design data (liberty, Verilog, SPEF, SDC)

Tcl Tests

• Integration-level tests exercising the full STA flow through Tcl commands
• Each test includes a .ok golden reference file for output verification

Note: Upstream Merge

This branch includes the upstream STA rel_3.0 merge (PR #288), which introduces the Scene/Mode architecture replacing Corner, enum class migrations, warning format changes, and Tcl command renames. All tests have been adapted to these API changes.

Test plan

• All 6,159 regression tests pass (ctest -j64)
• C++ tests: 5,854 pass
• Tcl tests: 305 pass

🤖 Generated with Claude Code

[jhkim-pii]

The PR title is misleading.
The actual title is Add new Tcl and C++ test cases (but I cannot edit it because the author of this PR is openroad-ci).

[maliberty]

Looking at https://jenkins.openroad.tools/job/OpenSTA-Public/job/PR-294/1/pipeline-overview/?selected-node=55 I see

21:17:55  Error: regression, 11 can't read "-e": no such variable
21:17:55  % 

which seems like an error but the stage is marked as passed. I don't see that any tests ran.

[jhkim-pii]

I don't understand how the error is raised.

By the way, in this PR, ctest base regression is newly established. So the CI should use ctest (can use multi-core) instead of regression (single core).
@vvbandeira Could you please help?

[CLAassistant]

All committers have signed the CLA.

[maliberty]

Changing to ctest will be a big job and probably should be its own PR. This PR has two issues

1. Dockerfile.ubuntu22.04 ends in ENTRYPOINT ["OpenSTA/build/sta"] so you are not in a bash shell
2. When that is commented out I see (locally):

./test/regression
Test project /workspace/w4/tools/OpenROAD/src/sta/build
No tests were found!!!

so the runner doesn't work

[dsengupta0628]

I think this PR has one too many changes and it should be split to first checkin the new infrastructure? Just the CMakeLists and the folder structure with maybe 1 tests in each? Let @vvbandeira setup the new regression running methodology as part of OpenSTA's CI, and simply add the rest of the regressions?

I am also thinking if there is any way to consolidate so many regressions? Can we ask Gemini or whoever is your AI assistant, to combine some of them into single regressions- currently there are many thousands of them and very hard to review each, unfortunately. And going forward, whenever we make any development, we make sure to add regression to ensure the new code coverage.

[jhkim-pii]

@dsengupta0628 Thank you for your feedback.

[1]
I opened a new PR #300. Please review the test infra first.

[2]
How many test cases are good?
We can reduce the number of files or the number of test cases at the expense of some code coverage.

[dsengupta0628]

@dsengupta0628 Thank you for your feedback.

[1] I opened a new PR #300. Please review the test infra first.

[2] How many test cases are good? We can reduce the number of files or the number of test cases at the expense of some code coverage.

Thanks- I reviewed the test infra and had just one minor comment. Please see that PR

Regarding how many regressions are good: there isn't a correct answer to this- I would have thought a few 100 to begin with (~10 per module, C++ tests can be more), but you mentioned these run very fast so I suppose it is okay to keep them, and as we go forward, and hit something problematic, we can remove a regression or update it. I assume we will eventually start incorporating many consistency checks, and assertions in code too in our regression suite, so it may explode the testing time- but we will cross that bridge when we get there.