Is it possible to write a unit test (as opposed to an integration test) in the following scenario:
- I have a list of
Fooobjects, some of which already exist in the database, some don't
- I want to iterate over the list, update the ones I already have in the database and add new ones
So, I write a test which has a
FooImporter with an
importFoos(List<Foo> foos) method. And then I need to mock out my DAO layer, so I mock the
FooDAO which gets injected into the
FooImporter...and then I'm feeling like I'm testing the implementation not the behaviour! In my test I end up with a bunch of expectations on calls (e.g. I put in an "existing"
Foo record, then I mock the behaviour of the
FooDAO to return true on the check for duplicate, and then add an expectation for the insert behaviour etc.)
So can I actually unit test this close to the data layer effectively, or should I be integration testing? And if so, can this not be done sensibly in a TDD manner?
(Before this gets flagged as a duplicate, this question is actually about the talk which inspired this question but the answer doesn't really convince me that this solves the coupling of tests to implementation behaviour.)