Is code that is impossible or hard to test necessarily bad? Many unit-tests and TDD evangelists would answer “YES”. I am personally not so sure. Consider this code:
Here we have a UserRegistrator object, that… registers users. For new users it also generates a password of length 8. Now, the question: how do we test this fact? (which we should: all business rules should be tested!
We have a “new User” hardcoded which we cannot unit-test (not easily, anyway). Does it make this code itself bad? I don’t think so - as it does exactly as per requirement. If I ever want to replace the “new User” with something else I want to have to go in this code and write manually what that other thing would be.
Is there any reason except difficultly of testing why this code may be considered “bad” code? Is there any valid use case for which I’d need this dependency not hardcoded? Not really.
Unit-tests are a “must have”. If you have time and money to build a robust infrastructure covered with unit-tests and functional tests you must try to test every business rule of your domain logic. What I suggest is not to forget that tests are “helpers” and should only influence your code when there is no other choice.
Whether there is choice depends on many things. PHP developers are not particularly in luck - in Ruby, for instance, that UserRegistrator example could be tested easily. Therefore, one could say that it’s not the code that is bad, it’s the language features and testing utilities that are not good enough.
newin your business logic. Only do that in factories/service locators/dependency injection containers. This is the most popular one, however adding lots of headache.
For BasicCRM application I’m going to go with the second option.
More on testing can be found in this post.