When you run or await an interaction, the expectation might be that the interaction has completed once it resolves. This is not true. In fact, this is precisely why convergent assertions are used in conjunction with interactors. To assert that the interaction has happened.
What interactions await on, however, is when the interaction is able to happen. Not that it has happened.
For example:
// interactor method
addTodo(todo) {
return this
.fillTodo(todo)
.submitTodo()
}
// add two todo items for our tests
await TodoList.addTodo("some todo");
await TodoList.addTodo("some other todo");
This example will attempt to add both todo items immediately, almost at the same exact time. This is because the interaction waits for the ability to interact, not for the result of the interaction.
To alleviate this, when can be used inside of an interactor method
addTodo(todo) {
return this
.fillTodo(todo)
.submitTodo()
// wait for the todo to be added to the list
.when(() => this.lastTodo === todo)
}
Since this might be the desired behavior, we should make this easier to achieve.
Interactor when should be able to accept a string that will perform a simple check for boolean properties. This would allow a simpler chaining syntax for most use cases of when.
item.toggle().when(() => item.isComplete) // this...
item.toggle().when('isComplete') // ...becomes this
Support chainable interaction creators. This could eventually become the interface for custom validations as well (when is essentially a validation step anyway).
I'm still unsure of the syntax for both the not situation, and the naming of when chained with the property creator. It doesn't quite sound like what it's meant to do: "clickable when"... maybe waitFor?
When you run or
await
an interaction, the expectation might be that the interaction has completed once it resolves. This is not true. In fact, this is precisely why convergent assertions are used in conjunction with interactors. To assert that the interaction has happened.What interactions
await
on, however, is when the interaction is able to happen. Not that it has happened.For example:
This example will attempt to add both todo items immediately, almost at the same exact time. This is because the interaction waits for the ability to interact, not for the result of the interaction.
To alleviate this,
when
can be used inside of an interactor methodSince this might be the desired behavior, we should make this easier to achieve.
when
should be able to accept a string that will perform a simple check for boolean properties. This would allow a simpler chaining syntax for most use cases ofwhen
.when
is essentially a validation step anyway).I'm still unsure of the syntax for both the not situation, and the naming of
when
chained with the property creator. It doesn't quite sound like what it's meant to do: "clickable when"... maybewaitFor
?