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.

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

Add extra validation for the confirmed booking #5

Merged
merged 1 commit into from
Nov 16, 2023
Merged

Add extra validation for the confirmed booking #5

merged 1 commit into from
Nov 16, 2023

Conversation

nt-gt
Copy link
Collaborator

@nt-gt nt-gt commented Nov 15, 2023

No description provided.

@nt-gt
Copy link
Collaborator Author

nt-gt commented Nov 15, 2023

image

@nt-gt nt-gt requested a review from gj0dcsa November 15, 2023 11:00
@gj0dcsa
Copy link
Collaborator

gj0dcsa commented Nov 16, 2023

Good point, thank you, I made a mistake. Checks are always run all the way at the end in automatic mode, so if you have "UC1 - GET(1) - UC2 - GET(2)" and want to compare the state after GET(1) with the state after UC1, you need to explicitly store one state with a key like "{cbr}#afterUC1#request", another with "{cbr}#GET1#response" and then compare the two in the check. If you just save with "{cbr}" as key, that will keep getting overwritten during each action of the scenario.

@nt-gt
Copy link
Collaborator Author

nt-gt commented Nov 16, 2023

I am confused now. In your chat message, you implied you would change something that would fix the current pattern. And here you right "If you want per step state, you have to manually play human state machine".

If you are going with the latter, then I object to this feature as being useful. A computer is better at being a state machine and we should use leverage that. I want persistent state (what happened up til now) - not state from the future (what will happen in the actions coming a head of me).

@gj0dcsa
Copy link
Collaborator

gj0dcsa commented Nov 16, 2023

I'd suggest that we do this in 2 steps: first, I'll fix it tomorrow the "imperfect way", then we discuss how you think we should do things instead and adjust the implementation accordingly. Would that work?

@nt-gt
Copy link
Collaborator Author

nt-gt commented Nov 16, 2023

I'd suggest that we do this in 2 steps: first, I'll fix it tomorrow the "imperfect way", then we discuss how you think we should do things instead and adjust the implementation accordingly. Would that work?

The "imperfect" way is the one were I play human state machine and store the payload under which GET request where the value should be returned?

@gj0dcsa
Copy link
Collaborator

gj0dcsa commented Nov 16, 2023

The "imperfect" way in which you do nothing special and accept that the test fails until tomorrow, I fix it tomorrow imperfectly, then we discuss how we want this to work in the future.

@nt-gt nt-gt marked this pull request as ready for review November 16, 2023 14:21
@nt-gt nt-gt merged commit b2bb295 into dev Nov 16, 2023
1 check passed
@nt-gt nt-gt deleted the DT-647-test branch November 16, 2023 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants