I started studying JUnit and Mockito and I really don't understand. All the docs and the tutorials around are like "if call this method, then return this object. If the object returned is the one that I expected then test passed". But isn't it obvious that the returned object is the one that I expected? I fucking told it to return that object

yeah basically.

It comes handy when you want to add new feature in the method.

And expect previous tests/scenarios to work, because other modules depends on the previous functionality.

For the first time, yes it's that mundane.

Come back in 6 months and change that function or data it's returning, you'll want that test to go "hey bitch, look at me, I'm broken"

Why? So you know what else you "touched" indirectly without spending a week doing an impact analysis for every change.

You also don't just want to have unit tests, you should have some behavioural tests (BDD) to cover the scope of work trying to be achieved with the function(s) being utilised.

This helps prevent breaking actual user workflows.

(1/2) I actually really like to rethink about the usage of unit tests from time to time. Let's assume our code is meant to solve a problem. We might have solved the problem perfectly, but it is unlikely. So (and this might sound weird) there is a perfect solution to the problem and our code only aspire to act the same. That said, we can only slice the function once. Think of it as pinning down the perfect solution- "the perfect solution should do this and that". Where does mocks enter this definition? Well, we know there are different levels of tests. The unit test is used to check that the specified unit is correct. This means that only the inner code in it must work. So you need to separate the dependencies from the actual unit. Mocks allow you to do this by outing their responses to the test, removing their functionality from the test.

(2/2) If we return to the previous definition what this actually mean is that in the context of a unit the dependencies are not part of the perfect solution, so pinpointing them will not give you the definition of the code you test. This obviously is only my thoughts on the subject, of course there are many other definitions. Dijkstra for example thought that you should prove code mathematically. Others think that tests are only aspects of the solution, thus the test suite would always be imperfect (which takes you to a whole different kind of tests)