3 ms·

I’m talking higher level than that. Think about the acceptance criteria you would put in a user story. I’m specifically responding to this: > When you give up

I’m talking higher level than that. Think about the acceptance criteria you would put in a user story. I’m specifically responding to this: > When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You don’t need to personally write code that mechanically iterates over every possible state to remain in the driver’s seat. You need to describe the acceptance criteria.

skydhash 1y ago
I think your perspective is heavily influenced by the imperative paradigm where you actually write the state transition. Compare that to functional programming where you only describe the relation between the initial and final state. Or logic programming where you describe the properties of the final state and where it would find the elements with those properties in the initial state. Those does not involves writing state transitions. You are merely describing the acceptance criteria. Imperative is the norm because that's how computers works, but there are other abstractions that maps more to how people thinks. Or how the problem is already solved.
- JimDabell 1y ago
  I didn’t mention state transitions. When I said “mechanically iterate over every possible state”, I was referring to writing tests that cover every type of input and output. Acceptance criteria might be something like “the user can enter their email address”. Tests might cover what happens when the user enters an email address, what happens when the user tries to enter the empty string, what happens when the user tries to enter a non-email address, what happens when the user tries to enter more than one email address… In order to be in the driver’s seat, you only need to define the acceptance criteria. You don’t need to write all the tests.
  - javcasas 1y ago
    > "the user can enter their email address” That only defines one of the things the user can enter. Should they be allowed to enter their postal address? Maybe. Should they be allowed to enter their friend's email address? Maybe. Your acceptance criteria is too shy of details.
- sitkack 1y ago
  Acceptance criteria describes the thing being accepted, it describes a property of the final state. There is no prescriptive manner in which to deliver the solution, unless it was built into the acceptance criteria. You are not talking about the same thing as the parent.
motorest 1y ago
> When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You're describing the happy path of BDD-style testing frameworks.
- JimDabell 1y ago
  I know about BDD frameworks. I’m talking higher level than that.
  - motorest 1y ago
    > I know about BDD frameworks. I’m talking higher level than that. What level do you think there is above "Given I'm logged in as a Regular User When I go to the front page Then I see the Profile button"?
    - JimDabell 1y ago
      The line you wrote does not describe a feature. Typically you have many of those cases and they collectively describe one feature. I’m talking about describing the feature. Do you seriously think there is no higher level than given/when/thens?
      - exe34 1y ago
        Could you give an example? It's not that I don't believe there are higher levels - I just don't want to guess what you might be hinting at.
      - motorest 1y ago
        > The line you wrote does not describe a feature. I'm describing a scenario as implemented in a gherkin feature file. A feature is tracked by one or more scenarios. https://cucumber.io/docs/gherkin/reference/ https://cucumber.io/docs/gherkin/reference/ > Do you seriously think there is no higher level than given/when/thens? You tell me which higher level you have in mind.

skydhash 1y ago

I think your perspective is heavily influenced by the imperative paradigm where you actually write the state transition. Compare that to functional programming where you only describe the relation between the initial and final state. Or logic programming where you describe the properties of the final state and where it would find the elements with those properties in the initial state. Those does not involves writing state transitions. You are merely describing the acceptance criteria. Imperative is the norm because that's how computers works, but there are other abstractions that maps more to how people thinks. Or how the problem is already solved.

JimDabell 1y ago
I didn’t mention state transitions. When I said “mechanically iterate over every possible state”, I was referring to writing tests that cover every type of input and output. Acceptance criteria might be something like “the user can enter their email address”. Tests might cover what happens when the user enters an email address, what happens when the user tries to enter the empty string, what happens when the user tries to enter a non-email address, what happens when the user tries to enter more than one email address… In order to be in the driver’s seat, you only need to define the acceptance criteria. You don’t need to write all the tests.
- javcasas 1y ago
  > "the user can enter their email address” That only defines one of the things the user can enter. Should they be allowed to enter their postal address? Maybe. Should they be allowed to enter their friend's email address? Maybe. Your acceptance criteria is too shy of details.
sitkack 1y ago
Acceptance criteria describes the thing being accepted, it describes a property of the final state. There is no prescriptive manner in which to deliver the solution, unless it was built into the acceptance criteria. You are not talking about the same thing as the parent.

motorest 1y ago

> When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You're describing the happy path of BDD-style testing frameworks.

JimDabell 1y ago
I know about BDD frameworks. I’m talking higher level than that.
- motorest 1y ago
  > I know about BDD frameworks. I’m talking higher level than that. What level do you think there is above "Given I'm logged in as a Regular User When I go to the front page Then I see the Profile button"?
  - JimDabell 1y ago
    The line you wrote does not describe a feature. Typically you have many of those cases and they collectively describe one feature. I’m talking about describing the feature. Do you seriously think there is no higher level than given/when/thens?
    - exe34 1y ago
      Could you give an example? It's not that I don't believe there are higher levels - I just don't want to guess what you might be hinting at.
    - motorest 1y ago
      > The line you wrote does not describe a feature. I'm describing a scenario as implemented in a gherkin feature file. A feature is tracked by one or more scenarios. https://cucumber.io/docs/gherkin/reference/ https://cucumber.io/docs/gherkin/reference/ > Do you seriously think there is no higher level than given/when/thens? You tell me which higher level you have in mind.