April 12, 2018

“Frameworks are tools, not ways of life”

I’m in the process of doing some research for my upcoming course Up and Running with TDD (no one has ever accused me of being creative), and I ran into a blog post by Uncle Bob Martin.

He says,

Frameworks are tools, not ways of life.

Frameworks can be very powerful and very useful. Framework authors often believe in their frameworks. The examples they write for how to use their frameworks are told from the point of view of a true believer. Other authors who write about the framework also tend to be disciples of the true belief. They show you the way to use the framework. Often it is an all-encompassing, all-pervading, let-the-framework-do-everything position. This is not the position you want to take.

Look at each framework with a jaded eye. View it skeptically. Yes, it might help, but at what cost. How should I use it, and how should I protect myself from it. How can I preserve the use-case emphasis of my architecture? How can I prevent the framework from taking over that architecture.

Testable Architectures.

If you system architecture is all about the use cases, and if you have kept your frameworks at arms-length. Then you should be able to unit-test all those use cases without any of the frameworks in place. You shouldn’t need the web server running in order to run your tests. You shouldn’t need the database connected in order to run your tests. Your business objects should be plain old objects that have no dependencies on frameworks or databases or other complications. Your use case objects should coordinate your business objects. And all of them together should be testable in-situ, without any of the complications of frameworks.

This ties nicely into a blog post I wrote about extracting logic from your controllers and putting it into service classes.

I use Laravel at work, and it has a very specific opinion about testing, namely write mostly feature tests with some unit tests for your models.

I’m not saying that’s a bad thing.

I just prefer Uncle Bob’s approach of writing isolated unit tests.

Are you new to Test Driven Development?

Join the mailing list! :)