If your unit test has a bunch of mocked up dependencies which you puppet to do whatever the fuck you want. Something could be improved perhaps

- write a test at a lower level if possible where the dependencies can be abstracted away, or you pass down what you need from them
- write a higher level integration test, i.e. which uses real spring context instead of mock dependencies

But my senior tells me that a unit test will almost always mock all of its dependencies, it should only test the logic in it's tiny atomic piece of work. Mock everythign else out.

Devrant, how do you unit test? I'm looking to learn more on the topic and hear how others do it.

The clue of unit testing is in the name.

There are cleaner ways to write tests in a way that doesn't show all details about the dependency when stubbing it, but if you want to test more than a unit then it's not a unit test.

P.S. it could be a very good idea to abstract setting up the dependencies in order to write very clean tests. To me tests need to be as clean or cleaner than production code or it will reach a critical mass of unmaintainable test code.

I'm not an expert in unit testing...

But it should be obvious that if you need large quantities of objects in a class - which then require mocking in a unit test - something is very fishy and stinky in the code....

The necessity of mocking a lot of objects for one unit test is in my opinion a sign of bad code - fix the bad code instead of sugar coating it with tests.

For me unit tests should be simple and trivial with the least complexity...

your senior is right in my opinion. You're supposed to test one *unit* of work at any point.

If you have 5 large tests, running real context, and something breaks, you have no good way to pinpoint what broke, it could be anything from bad environment, through bad data, to bad processing. In that case you're not writing unit tests but integration tests using JUnit, which is perfectly fine in my opinion, but it's a completely different type of test

But if you write 200 tests, each testing only a small unit everytime you build and rebuild. Even the smallest deviation from the correct output can be immediately tracked down and fixed. These are also much more predictable, easier to trust and much faster to load and run. Unit tests are the thing you want to run a lot of and it shouldn't take too much time. These should even be able to run in parallel without affecting each other at all

IMO Whether or not you use mocks depends on what layer your unit is in. Domain layer aggregates - no,
other layers - yes.

They are both valid approaches but the general advice is to mock as less a possible. That is only external communication. The more layers in an application the better this becomes.
https://testing.googleblog.com/2013...

That said there is a downside. If you test everything with real code a bug in a dep can make other unit tests fail (simulating what would happen in the app) making it harder to pinpoint.

When layers are not important but different situations like when writing a library instead of an app mocks can give you greater control of test input/output and your tests become faster.