You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to get my head around this library and I'm having some trouble understanding how I'm meant to structure Effects that are built out of other Effects, and how to test them. Let's say I have an Intent that represents getting text input from the user:
@dataclass
class GetInput:
value: str = None
I write a @do-annotated generator function for it:
But how do I encapsulate these two Effects into one "thing", in a way that can be tested without having to know about the individual sub-Effects that comprise it? In other words, what I would like is to have this:
@dataclass
class PrintLowercasedUserInput:
prompt: str = None
@do
def combined_effect(prompt):
yield Effect(PrintLowercasedUserInput(prompt))
def test_combined_effect():
prompt = "enter something: "
seq = [
(PrintLowercasedUserInput(prompt), lambda x: "the quick brown fox"),
]
effect = combined_effect(prompt)
assert perform_sequence(seq, effect) is None
In such a way that PrintLowercasedUserInput somehow encapsulates the action of the print_lowercased_input generator.
I'm finding it really hard to express what I want with the right vocabulary because this is all quite new to me. Basically when I'm writing tests for a large application I don't want the seq in the test to be full of very low level actions, I want to group them together into logical units, each of which has tests itself. Am I making any sense?
The text was updated successfully, but these errors were encountered:
@ckp95 yeah, sure, that makes sense. There are two strategies I have used:
I think the simplest and most practical is to write test utility functions that correspond to your encapsulated, multi-step effects, so your higher-level tests can construct effect sequences by concatenating together the results of these utility functions. e.g.:
deffox():
return [
(GetInput("enter something: "), lambdax: "The Quick Brown Fox"),
(PrintString("the quick brown fox"), noop)
]
and then you would set your seq to seq = fox() + [...] when testing those effects in conjunction with other ones. (parameterize fox as necessary).
The other way would be to do what you were hinting at in your example test, and actually create a new application-level Intent called PrintLowercasedUserInput which, in its performer, performs the other effects. You can then skip the sub-effects like your final example does. I generally don't use this pattern1
I'm trying to get my head around this library and I'm having some trouble understanding how I'm meant to structure Effects that are built out of other Effects, and how to test them. Let's say I have an Intent that represents getting text input from the user:
I write a
@do
-annotated generator function for it:And I test it like this:
So far so good. I also want to have an Effect that represents printing something to the screen, so I write this:
That works fine too.
If I want to combine these two, with some additional processing (converting to lowercase) I know I can do something like this:
But how do I encapsulate these two Effects into one "thing", in a way that can be tested without having to know about the individual sub-Effects that comprise it? In other words, what I would like is to have this:
In such a way that
PrintLowercasedUserInput
somehow encapsulates the action of theprint_lowercased_input
generator.I'm finding it really hard to express what I want with the right vocabulary because this is all quite new to me. Basically when I'm writing tests for a large application I don't want the
seq
in the test to be full of very low level actions, I want to group them together into logical units, each of which has tests itself. Am I making any sense?The text was updated successfully, but these errors were encountered: