One of my many roles at Mint.com is the lead test engineer. I believe I was appointed this role by our CEO, because I …
One of my many roles at Mint.com is the lead test engineer. I believe I was appointed this role by our CEO, because I am pretty good at thinking through use cases, setting up testing infrastructure, and being diligent about having unit tests for our core functionality and making sure that they pass daily.
Lately, we’ve noticed that our test cases are brittle, and have poor coverage mostly because of feature growth. My boss proposed that we seek a new approach to how we write and manage our unit test cases that is scalable and easy to practice under time constraints. So today, during one of the most productive and interested meetings I’ve ever had in my career, we discussed the trade-offs between using Stubs versus Mock Objects for unit testing. Our discussion was directed by the following requirements:
1. Little to no use of a database
2. Test logic at the controller level (servlet/ JSP) and at the service level.
3. Simple template that can be re-used to write additional test cases and doesn’t require complete knowledge of back-end architecture.
As a homework assignment for the meeting I read Martin Fowler’s “Mocks Aren’t Stubs”; Mackinnon, Freeman, and Craig’s “Endo Testing: Unit Testing With Mock Objects”; and a few sections from the book “Test Drive Development”. I thought each of these resources presented interesting insights into testing in general.
Fowler’s article introduced me to behavioral testing, which is the concept that in an application engineers should test the interaction amongst classes. Contrast this to functional verification, which is inputing data and then verifying the end results for accuracy.
This is the first time I had been presented with the concept of behavioral testing, and I realize it makes a lot of sense for a scalable web application, because the order and sequence of method invocations is just as important as data accuracy. Running code off of various servers, and across different layers has a huge impact on the data, so its just as important to test the interaction as it is to verify the data values.
Mock objects are the means by which engineers can do behavioral testing, because Mocks are programmed using expectations. Expectations are either a list of methods to call sometimes in a particular sequence, and/or values that a method may return. When a test case is run it simulates the behavior in a system using the Mock objects in place of POJOs, and verifies that the expectations were met.
Thus, Mocks do not contain all the functionality or attributes of a POJO, but serve in place of them by containing enough knowledge in the form of abstractions to test the interactions of the application.
