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.
{ 0 komentar... read them below or add one }
Posting Komentar