What is the expected enhancement?
With introduction of pulse ScheduleBlock (see #5679), the software implementation of the qiskit pulse was drastically updated while minimizing the impact to user API. However, the unittests are still based on the old codebase structure and there are many redundant/duplicated tests.
Basic changes based on the ScheduleBlock are listed as follows:
ScheduleBlock is added as the output program format of the builder syntax.
pulse.transforms turned into a package, aiming at pass manager implementation.
- Alignment transforms became a class instance rather than callbacks to keep arguments attached to the macro.
- Parameter framework is replaced with the visitor pattern (see discussion)
- Parameter relevant test for any program representation can be tested in a single place now.
I suggest to reorganize test.python.pulse as follows:
We also need further discussion for granularity of unittest classes. These classes are prepared for a specific method, collection of methods (some behavior), or subclass-wise, i.e. seems no standard rule. This may make us easily miss important testcases and raise the bar for contribution. Perhaps need some guideline? Welcome suggestions :)
What is the expected enhancement?
With introduction of pulse
ScheduleBlock(see #5679), the software implementation of the qiskit pulse was drastically updated while minimizing the impact to user API. However, the unittests are still based on the old codebase structure and there are many redundant/duplicated tests.Basic changes based on the
ScheduleBlockare listed as follows:ScheduleBlockis added as the output program format of the builder syntax.pulse.transformsturned into a package, aiming at pass manager implementation.I suggest to reorganize
test.python.pulseas follows:pulse_test_utils.pyScheduleBlock,Scheduleand builder syntax.test_block.pytest_builder.pytest_channels.py(as-is)test_library.pytest_continuous_pulses.py,test_discrete_pulses.py,test_samplers.py, andtest_pulse_lib.pytest_continuous_pulses.pytest_discrete_pulses.pytest_experiment_configurations.py(as-is)test_instruction_schedule_map.py(as-is)test_instructions.py(as-is)test_macros.py(as-is)test_parameter_manager.pySchedule(this is indirectly tested with parametrized builder syntax test)test_parameters.pytest_parser.py(as-is)test_pulse_lib.pytest_samplers.pytest_schedule.pytest_transforms.pytest_builder.pyandtest_block.pyAlignmentKindclassWe also need further discussion for granularity of unittest classes. These classes are prepared for a specific method, collection of methods (some behavior), or subclass-wise, i.e. seems no standard rule. This may make us easily miss important testcases and raise the bar for contribution. Perhaps need some guideline? Welcome suggestions :)