George -
Answer is clearer and I am reminded of the two (complimentary) approaches.
Thanks.
On Thu, Jul 11, 2013 at 6:17 PM, George Dinwiddie
<lists@...>wrote:
**
Eb,
On 7/11/13 5:35 PM, Eb wrote:
Thanks George.
I am following that advice also (already) so very good to get affirmation
of that.
However, I realize my question was not clear enough so continuing from
your
answer, do you always verify behavior on mocked adaptors or are there
occasions where you don't? That is, you just mock them but don't verify.
I tend to use a state-based approach (aka "Detroit style") so I'm
usually verifying the result of the behavior. Often my test doubles are
simple fakes (data sources) or stubs (data sinks, but usually query-able
by the test).
When I'm testing with a test-double adapter, I try to be cognizant of
the assumptions I'm making about the 3rd party system, and write
integration tests for the real adapter to validate those assumptions.
This has saved my butt when a new version of the 3rd party system has
violated my assumptions.
I hope my question is clearer.
And I hope my answer is clearer.
- George
Eb
On Thu, Jul 11, 2013 at 4:16 PM, George Dinwiddie
<lists@...>wrote:
**
Eb,
On 7/11/13 2:28 PM, Eb wrote:
Hi everyone -
What criteria do you use to determine if a collaborator that is a
third-party should be mocked and the test should verify that the
collaborator was indeed called when it was supposed to be?
I wouldn't do that. I use adapters for third-party collaborators and
mock my adapters to verify behavior. I also write integration tests for
the adapter's interaction with the third-party.
Steve Freeman's advice is to never mock something you don't own. I've
only violated that advice when I needed to simulate error conditions
while testing my adapter.
- George
--
Want to speak at AgileDC October 8, 2013?
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------
--
blog:
twitter: @eikonne
