You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
parseClassicConditionExpression (in src/common/parsing/CodePreprocessing.cpp) has no direct unit tests. Every test that exercises it today lives in test/test_custom_code.cpp and runs the full end-to-end pipeline: load QASM code, spin up a DDSimulationState, run the simulation, and inspect amplitudes or classical bits.
Two problems with that coverage:
A parser bug shows up as a failed amplitude assertion, not as "the parser returned the wrong ClassicCondition". Localizing the root cause takes longer than it should.
Edge cases of the parser itself (malformed input, whitespace, leading paren, trailing garbage, invalid brackets, empty operand) are not systematically covered because writing a full QASM program to trigger each one is disproportionate.
Surfaced during the review of PR #463 while considering the follow-ups for parseClassicConditionExpression.
Proposed solution
Add a fixture (either in the existing test_parsing.cpp or in a new file) that calls parseClassicConditionExpression directly with a string and checks the returned std::optional<ClassicCondition> against expected values. Cover:
Valid cases: one test per comparator (==, !=, <, <=, >, >=), bracketed forms (c[0] == 1), bare register (c), bare bit (c[0]), input with leading (, input with surrounding whitespace.
Invalid cases: empty string, missing operand on either side, non-numeric right-hand side, malformed brackets (open only, close only, index empty, non-digit index, bracket not at the end), out-of-range integer literal.
Unit tests for other parsers in the file (parseFunctionDefinition, parseClassicControlledGate, etc.). Same idea, separate issue.
Testing parseBitRegisterRef directly. It lives in the anonymous namespace of the .cpp; the tests here cover it indirectly through parseClassicConditionExpression, which is what the outside world sees.
π€ AI text below π€
Problem statement
parseClassicConditionExpression(insrc/common/parsing/CodePreprocessing.cpp) has no direct unit tests. Every test that exercises it today lives intest/test_custom_code.cppand runs the full end-to-end pipeline: load QASM code, spin up aDDSimulationState, run the simulation, and inspect amplitudes or classical bits.Two problems with that coverage:
ClassicCondition". Localizing the root cause takes longer than it should.Surfaced during the review of PR #463 while considering the follow-ups for
parseClassicConditionExpression.Proposed solution
Add a fixture (either in the existing
test_parsing.cppor in a new file) that callsparseClassicConditionExpressiondirectly with a string and checks the returnedstd::optional<ClassicCondition>against expected values. Cover:==,!=,<,<=,>,>=), bracketed forms (c[0] == 1), bare register (c), bare bit (c[0]), input with leading(, input with surrounding whitespace.c2]accepted as a register name,@#accepted). These tests can start green against the current behavior and flip to expectstd::nulloptonce π Register-reference validation is incomplete in the parserΒ #468 lands.Out of scope
parseFunctionDefinition,parseClassicControlledGate, etc.). Same idea, separate issue.parseBitRegisterRefdirectly. It lives in the anonymous namespace of the.cpp; the tests here cover it indirectly throughparseClassicConditionExpression, which is what the outside world sees.