Java Reference
In-Depth Information
Instruments used for testing
As you can imagine, each kind of testing uses a different approach and often requires dif-
ferent testing libraries.
When you're writing unit tests, you have to just provide some method input parameters,
and validate if their outcome covers the expectations. To do this in Java, you probably
already use
JUnit
,
TestNG
, or
Spock
. When you're moving from bigger parts of code to
testing whole services, some problems may appear. It's often hard to separate the code
you'd like to test, to make it testable without running all the other services. You usually cre-
ate some mock objects that simulate behavior of modules you don't want to include in your
test. If you have an object whose methods you want to test, and if these methods depend on
another object, you can create a mock of the dependency rather than an actual instance of
that dependency. This allows you to test your object in isolation.
As an example, one common use case might be in database applications, where you would
like to test, for example, the user registration process but you don't want to run the whole
database (which means that you will set its schema, some initial data, and finally clean its
state manually after the test is complete). You can mock just the database interaction and
define the behavior of some methods execution, for example, your stub will always return
four users, which will be hardcoded in your test code.
This kind of approach, although very immediate to understand and put into practice, has
several limitations. Firstly, it relegates you into an artificial environment, where you will
often make invalid assumptions about the behavior and stability of that environment.
Secondly, you will end up with a hard-to-maintain mock code, which will allow your tests
to pass and give you the warm feeling of having done a great job.
Thirdly, sometimes it's very hard to isolate a service you'd like to test, and code mocking
all its interactions can be larger than the code of the meaningful tests.
So, even if mock objects may still provide some benefits to start systems, where you don't
have full implementations of a particular subsystem, it might be good to stay as close as
possible to the target environment that the code is supposed to run in. At some point, The
No Mock Movement (
Not Only Mocks Movement
) was launched pointing out that mock-
ing often takes too much time, and makes you focus on writing mocks instead of writing
tests.
