With the release of Isolator Version 5.3, we have added the ability to simulate 
external components based on the arguments passed to those components. We called this Conditional Behavior.
Our default is to ignore arguments, to fake a method without taking the arguments into consideration, neither the number of arguments (overloads) or the values of those arguments (conditional behavior).
There is a reason for this.
Lets see the values with which we create our API’s, taken from Roy’s post
- Consistency
- Discoverability
- Explicitness
- Single point of entry
- Readability
- Single way to achieve things
- Backwards compatibility
The value that I want to discuss is Explicitness: we decided early on to be as explicit as possible about the API, so that the least guessing needs to take place by the user
So how do we decide on our defaults?
We fight about them, we find out what will need the least guessing, but keep the tests short (Readable)?
We talk about what most users mean, what most users expect.
We talk about failing fast when writing the code and we talk about Brittle vs Fragile when running the code.
We argue about what default usage will break if the user changes (refactors) the production code, without changing its logic. We want those tests to succeed.
This is ultimately why we ignore the arguments, so that changing a value passed to a method or using an overloaded method instead, will not fail the test.
Those cases where the difference is required, are discoverable while writing the test. The test will fail fast, if an overloaded method needs a different behavior, or if the method acts differently based on its arguments, and that will allow the writer to add the conditional behavior.