23 August 2007

GTAC. Google Test Automation Conference

I'm at Google's Test Automation Conference in New York City (my old stamping ground from the '80's) and so far Mocks have been doing quite well. We had several mentions on his slides from Patric Copeland (Director of QA at Google).

There was also a presentation from Matt Heuser and Sean McMillan, "Examining Interaction-Based testing". I admit I feared a hatchet job but, actually, they presented a very balanced view. They had some good examples of Interaction Testing gone wrong, such as mocking out production code and not writing integration tests. They also pointed out the benefits of using TDD with mocks, including ending up with good code quality statistics implying good maintainability.

The one comment I had on the talk was to de-emphasise use of mocks to speed up unit test runs by mocking external (slow) resources. Our preference is to use mocks within our domain code but to try to write focussed integration tests at the outer boundaries of the system.

Labels:


Posted by Steve Freeman  20:13
Comments:
Hi Steve - in Rails testing I tend to (and have encouraged others to) mock ActiveRecord models to keep tests running fast. Given that Rails tends to have very shallow layers (i.e. the boundary objects at each layer are more or less the only objects in each layer), this works well for me (as long as there are integration tests).

Thoughts on this? Is it fair to accept Rails as a different beast in this context?
# posted by Anonymous David Chelimsky : 26 August, 2007 13:21
 
That's possible. I haven't done enough Rails to say anything meaningful on this. And, as you point out, there must be some integration tests too.
# posted by Blogger Steve Freeman : 26 August, 2007 15:50
 
Interaction Based Testing?? Right.. Steve, you made the point, which is: mocks are are great design tool! And sure, you should test around subsystem edges, you should test your performance expectations, and you must test that your app can talk EDI protocol, etc. But that is different, that is is like saying "well you should create a unit test to re-create every defect". Yes, you should. But do we call that Test Driven Bug Fixing??

I think most people miss the point: using mocks, in a crude way, is about getting an executable model, even if you need to describe it in [unit test] code. One you can play with to tease out requirements, iterate a design, or elicit an outbound interface as a set of expectations. From a functional perspective, if you get it right, why should you need to test it? But hey! That's what happens when you call it TDD...
# posted by Blogger Simon : 03 September, 2007 19:16
 
Post a Comment

Links to this post:

Create a Link



<< Home

© The authors