

Unit Testing Without Mocking Makes a Mockery  - codereview1
http://www.drdobbs.com/testing/240001524

======
malux85
Mocks are useful, but their example of mocks being used to increase speed is a
bad thing (tm)

I believe your tests need to run as close to real data as possible. This
includes making calls to the DB, and making calls to API's.

If you're using mocks to speed up your testing, I think you're attacking the
problem in the wrong way. If you're tests are truly isolated and atomic then
they can be executed in parallel. Some tests will rely on the results of a
previous test, so break the testing into modules and execute the modules in
parallel.

Mocks are handy, but should only be used when real data isn't appropriate.

~~~
hutteman
I think you're confusing unit tests with integration tests.

In integration tests you should indeed run as close to real data as possible
and execute your system's entire stack, including database calls. Unit tests
on the other hand should be used to test small decoupled parts of the
codebase.

If you have a class that implements certain business logic against data that
would normally be retrieved from a database, a unit test using mocks can test
this business logic in isolation, feeding a variety of data through the method
to test a large number of scenarios and edge cases.

Speeding up this kind of testing is definitely important; test suites using
mocks that can run in seconds can be executed after most changes to give
immediate feedback to developers, whereas integration-type tests that might
take an hour or more would slow down development too much to do this.

Integration tests are important as well, and should be run possibly nightly or
at least prior to any release. They cannot be used to give the kind of
immediate feedback that truly decoupled unit tests give though.

