Isn't it more of a leap to assume that I've examined your tests to see that you're using dependency injection and that the argument is only meant to be used by tests? I would think that as a general rule you want the public interface to your classes to be as intuitive as possible and to work as advertised. As a consumer of your Article class If I see a publish! method that takes a published_at argument I think I should be safe in assuming that I can pass in a future date as the argument and expect that the rest of the system behaves correctly. Of course you could document that the argument is only for testing purposes but as user of the Article class I would question why the argument is there in the first place if I can't use it. I understand that due to language or framework limitations that there may be times that you need to pollute the public interfaces of your classes with unnecessary methods or parameters but that should be the exception rather then the rule. I still think that there is almost always some kind of cost to future flexibility whether it's additional code, more documentation or in the Article example pollution of the public interface. Sometimes you recover your costs, sometimes you make money on your investment and sometimes you lose big time. As always there are trade offs to every solution and no silver bullet. --- Lloyd Kupchanko