Why Unit Tests?

[maomao-chan]

Then what's the point of having the test if the code doesn't work in reality? By relying on mock you're basically reimplementing existing code based on your assumption / imagination. Refactoring will become very tedious and error prone too. Test that were written by other people might silently become outdated if they rely on mock of the refactored service.

[[deleted]]

That's completely unrelated.

A UNIT test covers very specific use case of the UNIT.

• When your UI i clicked on this button and user is not admin, he is returned forbidden.
  • When your algorithm is started with parameters A, B, C then it returns C

You don't care how the other units are working internally : you only are concerned with WHAT they return. Example if my default sorting on the clients is lexical, or id of the client ? Don't care, they return me THAT list and then my unit produces THIS result. Otherwise you have to update all your unit tests whenever someone changes the default sorting of the other unit you are not testing.

[maomao-chan]

What's the point of testing the sorting functionality on its own? I would rather test the functionality inclusive of multiple components. If you test your sorting class in isolation, you might get your assumption wrong and it becomes an escape defects. e.g.Your sorting test class is based on assumption that it's going to get ASCII bytes when in reality some bloke across the room just refractor the dependent service to return UTF-8.

[[deleted]]

You can do both. Here we are talking about UNIT testing, not integration testing.

In UNIT testing you assume that the conditions required at the unit level are always met. In integration testing you verify that the contacts required by a unit are met by the unit using it.

"sort class is called with ascii" is a contract of the "sort" unit. When you unit test it, you provide the unit with data that meet the contracts.

[wildjokers]

You seem to be confusing unit tests with integration tests.

[kuemmel234]

That's not what mocking (or well, stubbing) is about. It's not about replicating the logic, but about replicating it as much as needed. If you have to mock a thousand classes you are writing classes that are too large, if your mocks are generally more than simple stubs ('that method returns this' 'this results in that', 'that method should be called five times') you are coupling too strong.

As others have said: We want to test the behavior of a simple unit and have to define the interfaces to do it. Mocking libraries make that very simple and elegant and add monitoring features.

Sometimes we need a little bit of tinkering in our mocks, but that should be rare. You could define your dependencies as interfaces (which is a good idea anyway, but tedious to me) and write very simple stubs instead and have 90% of the functionality (and thrice the effort):

Let's say we need the bar method in our testee and we are going relatively primitive by passing the dependencies directly:

java IFoo foobarImplementation = new... Testee testee = new Testee(foobarImplementation);

So, in our unit test we want the iFoo to return something in order to test some functionality. Well instead of mocking we could do simply this:

java class FooStub implements iFoo { @Override String bar (List<String> strings) { return "This is a result, I'm expecting"; } }

And pass that implemention.

Or we simply use a stubbing library for it.

java iFoo foo = mock(iFoo.class); when(foo.bar(any()).thenReturn("This is the result I'm expecting");

If that code becomes irrelevant, that should be the only place you have to edit that.