As per Mark’s reasoning (pasted at bottom), I still think that by mocking he means to verify behavior/interaction on the 3rd party components. Unit testing somebody else’s code is not one’s responsibility and secondly writing a wrapper on top of each library for testability seems weird to me IMO.

Well, I follow your recommendation just that I want to decipher Mark’s suggestion.

———————-
There are a couple of reasons why doing this isn’t a great idea:

1) We have no idea what the correct method calls are in the first place so we’re just guessing based on looking through the Hibernate code and selecting the methods that we think make it work correctly.

2) If the library code gets changed then our tests break even though functionally the code might still work

———————-

no, a test double can be a mock or a stub… it’s just a term that means that the implementation of one of the dependencies will be replaced with something else. Regardless of whether it’s a mock or a stub.

And i still recommend the same guidelines as i did originally in this post, regardless of the point Mark makes in his post

>>> If a component uses an external resource (a database, a file, a remote service, …) either directly or indirectly, then i always replace the component with a double when i’m testing code that is dependent on it.

Now above statement go against Mark’s.

Test Double in your post seems to be PURE stub however by ‘mocking’ Mark is referring to stub in “verifying behavior/interaction” context.

Can you make it little bit more clear?

The second project has about 7000 tests, which take about 10 minutes to run. The biggest problem with this project is not the time wasted running the tests, but the time wasted on writing the setup for each test because they have a horribly complicated data model. For every new test, they are wasting a lot of time just to be able to write tests. There’s also a large maintenance cost involved… i’ve heard some developers claim that they often spend 4 hours or more fixing/modifying tests that are related to a fix/modification in the code which only took them about an hour to do. Those tests are also extremely fragile, up to the point where i’m actually suprised if the project has a completely green build. It doesn’t happen often. And it never lasts long.

Of course this doesn’t scale well, takes a lot more setup/teardown work and is generally a bad idea, but the hard part is convincing people that separation of concerns (and single responsibility principle) is often the root cause of this database dependency problem. One person I work with has adopted (db dependent quasi-unit) testing and loves it, so I don’t want to discourage them. I’d rather have slow tests than no tests at all.