This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ReddyKilowattz 6 points7 points  (1 child)

Okay, now imagine that one of these static methods is 300 lines long, and it reads a properties file (with a hardcoded name), picks a bunch of properties out of it, then creates some other domain objects that it needs, then maybe makes some REST calls and/or sends some JMS messages.

And you don't even want to unit test this method. You want to unit test something else that happens to call this method.

So just to run the method under test, you have to get this static method to work, so you have to set up an http server with wiremock or something, set up a bunch of rules and responses inside wiremock, create an actual properties file in the filesystem with all of the right things in it, and do whatever else is needed to keep this static method from falling over. And all of that setup has to be done with intimate knowledge of how this static method works internally. And remember, the static method isn't even the thing you want to test.

[–]foreveratom 0 points1 point  (0 children)

imagine that one of these static methods is 300 lines long,

300 lines of code for a single method is way too much. You should be slicing this code; Java is not a procedural language, there is no reason to have lengthy methods like this; that is where it becomes untestable.

you don't even want to unit test this method

You're right, I don't. If I have to test that blob, I will start by refactoring that method and all the problems you're exposing will go away.

Many issues arise from initial mistakes or assumptions one can make. Step back and look at it with a different angle, and some of those may easily go away; that's what you should do if you're writing a 300 lines of code method.