Yes, it loads all the stubs defined in the fixture.
If you need more customization for different edge cases, then you can split your stubs between different fixture files.
For example, you can define a default behavior (stubbing a method with no arguments) in one fixture. Then in another fixture define more specific behavior for some arguments:
# Default behavior for Translate.call(text, from: source, to: target)----class:Translatechain:callactions:-raise:TranslationNotFoundError
# Specific definition for Translate.call("Color", from: "en", to: "de")----class:Translatechain:callarguments:-Color-:from:en:to:deactions:-return:Farbe
It doesn't matter, whether you define stubs in one fixture, or split them between several files. The only thing that matter is the loading order -- in case you stub the same method with the same set of arguments twice.
The only reason to split fixtures is arranging them in a more readable manner. Personally, I prefer just to copy-paste the whole fixture for every single case and see no reason in DRY-ing them.
Yes, it loads all the stubs defined in the fixture.
If you need more customization for different edge cases, then you can split your stubs between different fixture files.
For example, you can define a default behavior (stubbing a method with no arguments) in one fixture. Then in another fixture define more specific behavior for some arguments:
It doesn't matter, whether you define stubs in one fixture, or split them between several files. The only thing that matter is the loading order -- in case you stub the same method with the same set of arguments twice.
Thanks. And since the stubbing happens in a
before
(I assume:each
) the stubs are reset each time and persist only in the current context.Exactly!
The only reason to split fixtures is arranging them in a more readable manner. Personally, I prefer just to copy-paste the whole fixture for every single case and see no reason in DRY-ing them.
But I can imagine cases when splitting worths it.
Thanks for the reply. I suppose you can use the alias feature of YAML to share sections of the configuration, at least within the same file.