Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hazardous behaviour of ScenarioDefinition.getstep() #79

Open
alxroyer opened this issue Mar 19, 2023 · 1 comment
Open

Hazardous behaviour of ScenarioDefinition.getstep() #79

alxroyer opened this issue Mar 19, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@alxroyer
Copy link
Owner

Depending on the context, the ScenarioDefinition.getstep() may return hazardous step references, especially when the index parameter is set with a negative value (-1 by default).

When called while building the scenario, the method returns the latest step up to what has been built then.

When the same call occurs when the scenario is under execution, the scenario has been fully built at this time, thus a future step can be returned.
@alxroyer
Copy link
Owner Author

alxroyer commented Mar 19, 2023 •
edited
Loading

Possible solutions:

  • Make getstep() stop iterating when the requesting step is encountered. Problem: such a requesting step is not known in the current implementation.
  • Restrict getstep() with the following limitations:
    • Limitation description: no negative index when the scenario is under execution. Raise an execption if so.
    • This limitation seems acceptable in as much as users should rather make their getstep() calls for good and save step references when building the scenario.

@alxroyer alxroyer added the bug Something isn't working label Mar 19, 2023
alxroyer added a commit that referenced this issue Mar 27, 2023
@alxroyer
Update 'TODO.md'
51b7ffc 
Issue #79 and #80 references
alxroyer added a commit that referenced this issue May 9, 2023
@alxroyer
Avoid hazardous results for ScenarioDefinition.getstep() (#79)
f393569 
Implementation details:
- `StepSpecificationType` augmented with a tuple option: (spec, index):
    - `StepDefinitionHelper.matchspecification()` and
      `specificationdescription()` updated consequently.
- `index` parameters removed from `ScenarioDefinition.getstep()` and
  `expectstep()`.
    - `ScenarioDefinition.getstep()` implementation updated.
    - `step_specification` parameters made mandatory by the way.
alxroyer added a commit that referenced this issue May 9, 2023
@alxroyer
Fix mkdoc class reference missing typing.Tuple (#79)
a6615da
alxroyer added a commit that referenced this issue Jun 16, 2023
@alxroyer
Merge branch 'int/v0.2.2+' into bugfix/#79/step-spec
6dc0d6d 
# Conflicts:
#	src/scenario/_assertionhelpers.py
#	src/scenario/_assertions.py
#	src/scenario/_scenariodefinition.py
#	src/scenario/_scenariorunner.py
#	src/scenario/_stepuserapi.py
alxroyer added a commit that referenced this issue Jun 16, 2023
@alxroyer
Avoid hazardous results for ScenarioDefinition.getstep() (#79)
c5bd140 
Implementation details:
- `StepSpecificationType` refactored and split
  as `StepDefinitionSpecification`
  and `StepExecutionSpecification` classes.
- Step specification classes and types exported
  with the `scenario` package.
- `index` parameters removed from
  `ScenarioDefinition.getstep()` and `expectstep()`.

Miscellaneous:
- `StepExecution` internal methods hidden
  in a `StepExecutionHelper` class.
- `Assertions` routines implementation improvements:
  `asserttimeinstep()` and `asserttimeinsteps()`
- Delivery documentation improved.
alxroyer added a commit that referenced this issue Jun 16, 2023
@alxroyer
Update TODO.md (#79)
def5011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@alxroyer