In Clean Code, Robert C. Martin states that no parameter methods are better than those with very few parameters. I'm kind of confused as no parameter methods are usually harder to unit test and tend to be more coupled.
I think his rational is that since a class should only fulfill one very specific task the coupling is alright but what about unit testing?
Also the approach towards atomic methods would favor reuse of the methods so why would you try to couple them to instance methods preferably?
My understanding of Uncle Bobs claim is: think carefully about the life cycle of your objects.
I for my self found that quite often I can turn some of the method parameters into constructor parameters since they do not change during the use of the object.
In contrast to Uncle Bobs I don't find no parameter methods superior. That is because my methods often create a return value that is used in the next method. Adding that return value to the objects state instead of passing it as parameter to the next method decreases readability because it hides a dependency between those methods. This also becomes a problem when you apply your IDEs automated refactoring move method which makes the (temporary) member variable accessible for the object the method moved to...
Also it opens the possibility to change the order of method in a wrong way. The "no state" version would throw a compiler error in such case...
The advice of Uncle Bob should be taken with a large grain of salt. It is always important to understand the context for advice and the trade-offs involved.
Bob is a proponent of the object-oriented paradigm. The underlying premise is you want to follow the OO paradigm. If you prefer a functional style or some pragmatic middle ground, his advice might not be for you.
If I understand you correctly you prefer to test methods individually. This is much simpler if there is less reliance on object state, and more on parameters. Pure side-effect free functions are especially easy to test. But this is functional style. In OO style, the "unit" is the object, not the method. You don't test a single method in isolation, you always test the behavior of an object.
When you say methods with fewer parameters are more coupled, I assume you mean more coupled to the state of the object and other methods on the same object? This is not necessarily a bad thing in OO - rather you try to achieve low coupling between objects and high cohesion for the object.
I don't think anybody have proven one paradigm to be superior to another, so this all comes down to opinion (or religion). But if you accept the premise that you want to strive for a pure OO architecture, then the advice of Bob makes sense.
In Uncle Bob's coding style, there are many small methods with descriptive names that take no parameter but are just there to structure the code for the reader. You will usually not unit-test these methods directly, but through higher-level methods of a class. Do not make the mistake to think that you have to have a corresponding test method for each method in the class under test.
Secondly, as correctly stated in the comments, methods with no parameters still know all about the internal state of the class, they have the impleicit this parameter. Testing a method's behavior thus depends on the parameters and the state of the surrounding object. If you have no parameters, that is actually less state to think about when testing a method. I you call a method from a test, you configure it by changing the object's state. Were there parameters, this would be an even larger state space for your tests to cover, so technically you could say having zero arguments is the best case.
That said, in the end it still depends on your actual code whether it is easy to test. Say you have a function f(int a) with one parameter. You could always make int a a field of the class and the function f() now has zero parameters. This would not make it easier or harder to test.
