Before using TDD, I was a big fan of separation of concerns, single responsibility and inversion of control. These things have proven over and over again to be priceless.
When I started using TDD I loved is how it enforced these principles. I couldn't maintain or write tests without them. Testing even forced the need for dependency injection and inversion of control containers.
The tests started to validate and enforce important behaviors. Behaviors some people don't appreciate. Sometimes these had been a hard sell.
TDD became an easy justification for best practices. How awesome!
Enter mocking libraries that don't require DI. You can mock everything from constructors to static methods. Mocking methods on the CUT is as easy as creating a new class for that responsibility.
With this, its easier to make a large class and use static utils and real constructors. Now you can test without adding those pesky things that add to the confusion of object oriented code... you know stuff like interfaces, polymorphism, encapsulation...
If we don't need DI or interfaces for testing, then why do we need them? If testing can happen without it, then that behavior isn't driven, right? Why can't I make a big class if its testable?
But these design principles have been around for a long time and for good reason. DI, single responsibility and separation of concerns were not born from testing.
Subscribe to:
Post Comments (Atom)
4 comments:
I could not agree more. The core principles of OO exist for reasons that promote good code and sustainable systems, long before TDD. TDD, BDD, et cetera, definitely help developers adhere to these principles, but if they are not using TDD, this does not mean they are exempt from writing good code. Testing has been my biggest asset for helping younger and seasoned developers learn and live good OOD.
Great stuff. The main reason I switched from TypeMock to Rhino Mocks because TypeMock didn't force me to write loosely coupled code.
Separation of concerns - this is a core principle of problem solving. When did it become exclusive to OO?
TDD - Do one big project (in *whatever* technology) - stay in it for a while. If a developer is open to learning from the school of hard-knocks - it will get nailed down in their head forever.
Again, dont confuse it as being exclusive to software. I am sure they used it when developing the Apollo module - and I am sure they use it now when designing new drugs at Pfizer.
By confining it to one realm of problem solving (OOD in this case) - you are limiting your own powers of analogy and problem solving.
I find it irritating when I read blogs full of buzzwords, like TDD, BDD, or whatever. I come from the other extreme of course, and that is bad too. But these buzzwords can get between you and the problem you are trying to solve. There is a lucid pool of deeper abstraction once you punch thru the patterns. Thats where beauty lives.
Reminds me of the interview with the CTO of Amazon - the interviewer tried hard to put (buzz)words into his mouth. The CTO refused to accept that Amazon uses service oriented architecture (SOA). FYI , the Amazon landing page is composed of almost 100 portlets or apps - any other shop would have been (proudly) yelling SOA/WSDL until they were blue in the face.
Does anyone have recommendations on good articles on the single responsibility principle? What I'm looking for smells can be used indicate possible problems with a class or method doing too much.
Post a Comment