E Armitage wrote:IMO, it's much better to do away with mocks and use tools like arquillian so your tests run against a test/mock database rather than mocking your classes.
Junilu Lacar wrote:
E Armitage wrote:IMO, it's much better to do away with mocks and use tools like arquillian so your tests run against a test/mock database rather than mocking your classes.
Hmm, just took a brief look at Arquillian and it looks like it's concerned with integration tests. Here's one guy who would disagree with needing integration tests and doing away with mocked up DAOs for unit testing: http://www.infoq.com/presentations/integration-tests-scam If the name doesn't ring a bell, he's the author of "JUnit Recipes". I think I'm with J.B. on this.
E Armitage wrote:You just don't need to write lots of untested mocks anymore.
Junilu Lacar wrote:
E Armitage wrote:You just don't need to write lots of untested mocks anymore.
But that's the whole point of using mocks: so you don't have to worry about untested components. You make the mocks behave exactly the way you expect the components they represent to behave. That is, you are assuming that you are using 100% correct (fully tested) components. You're also making the assumption that when the real components are plugged in, they will work according to contract. If you're worried about the other components' behavior, then the problem is probably that you don't have enough tests for those components. That's not a mock vs. no mock issue. That's a trust issue.
Thanks for the link, I'll check it out.
E Armitage wrote:You didn't get my point. It's not the other components that are untested. It's the mocks themselves that are not tested (and I have seen and created bugs in mocks myself). The point is that you just don't need to write the mocks at all since it is now easy and cheaper to provide the real component. You still write comprehensive unit tests for those components as well.
E Armitage wrote:The argument is not about which approach provides better test coverage.
E Armitage wrote:The point is that you just don't need to write the mocks at all since it is now easy and cheaper to provide the real component...The Arquillian way just doesn't need the mocks to achieve it.
Junilu Lacar wrote:..
..This is because doing so makes the test run a lot slower. You want a unit test to run fast. Really fast. When you are unit testing a Business Service (eg. BalanceTransferService) that interacts with an Infrastructure Service like a DAO or Web Service endpoint, you absolutely should mock out that Infrastructure Service in your unit test for the Business Service. So what would be the Arquillian way of doing this without a mock?
E Armitage wrote:I really don't see how you can guarantee 100% tested mocks hand-crafted or otherwise. Even the JUnit fathers have pointed out that the tests of the test cases and their mocks is production code.
E Armitage wrote:The real question here is, why have the mocks at all when you have the real service available cheaply?
Donald Knuth wrote:"Beware of bugs in the above code; I have only proved it correct, not tried it."
Arquillian is an innovative and highly extensible testing platform for the JVM that enables developers to easily create automated integration, functional and acceptance tests for Java middleware