Originally posted by Lasse Koskela:
A unit test by definition does not touch an actual database. Instead, you unit test your DAOs in isolation from the database--usually against mock objects.
Originally posted by Bill Peck:
Sorry about the blank post.
Regarding Charles' question . . . Say a person was learning Java, but had a decent grasp of programming and software development. How many years of experience, generally speaking, would it take to have even the slightest clue of understanding of Charles' question?
The big issue here is when to use a mock or other double...
The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.
A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service...
The first thing to consider is the context. Are we thinking about an easy collaboration ... or an awkward one...? If it's an easy collaboration then the choice is simple. If I'm a classic TDDer I don't use a mock, stub or any kind of double. I use a real object and state verification. If I'm a mockist TDDer I use a mock and behavior verification. No decisions at all.
If it's an awkward collaboration, then there's no decision if I'm a mockist�I just use mocks and behavior verification. If I'm a classicist then I do have a choice, but it's not a big deal which one to use... The real issue is between classic and mockist TDD.