title: How does the functional programming recommendation for static methods influence testability?
body: <p>The more I dive into functional programming I read the recommendation to favor static methods in favor of non-static ones. You can read about that recommendation in this book for example:</p>
  
  <p><a href="http://www.amazon.de/Functional-Programming-Techniques-Projects-Programmer/dp/0470744588" rel="noreferrer">http://www.amazon.de/Functional-Programming-Techniques-Projects-Programmer/dp/0470744588</a></p>
  
  <p>Of course that makes sense if you think about functional purity. A static function stands there and says: "I do not need any state!"</p>
  
  <p>However, how does that influence testability? I mean, isn't it that a system with a lot of static methods becomes a pain to test (since static methods are hard to mock)? Or does mocks play a minor role in functional programming and if so: why?</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>Since there are doubts if the book really makes that recommendation. I will quote a little more. I hope thats ok for Oliver Sturm.</p>
  
  <p><strong>Use Static Methods</strong></p>
  
  <blockquote>
    <p>Static methods is one of the basic ideas worth considering as a general guideline. It is supported by many object oriented programmers, and from a functional point of view, functions can be made static most of the time. Any pure function can be made static.
    (...)</p>
    
    <p>Some may argue that the idea of always passing around all parameters means you're not exploiting the ideas of object orientation as much as you could. That may in fact be true, but then perhaps it is because object orientation concepts don't give as much consideration to issues of parallel execution as they should.
    (...)</p>
    
    <p>Finally, a guideline to recommend: when you have written a method that does not require acces to any field in the class it lives in, make it static!</p>
  </blockquote>
  
  <p>Btw, there have been good answers so far. Thanks for that!</p>