Despite what His Majesty, David Heinemeier Hansson may have said, unit testing is by no means dead. And, in fact, system testing is no more a complete testing strategy than 100% test coverage with unit tests. Let me explain.
Test Driven Development (TDD) is a philosophy that asserts testing is so important that the tests should be written first, to emphasize the design of the code. The idea is that by writing a failing test, and then writing code that passes that test, you end up with an overall better architecture.
In many development shops where I’ve worked, there’s a consistent struggle between developers who want to “do it right” and management that wants to “just get it shipped.”
The problem stems from the pride developers feel in their work coming up against the business realities faced by managers and company leaders, who are focused on making sure everyone gets a paycheck each Friday.
We’ve all seen it: we’re working along, and we come across code that just has a feel to it. It’s like déjà vu. You’ve seen this code before. You open another file – sure enough, there it is. The same code. Almost line for line.
In large code bases, it’s likely that there are dozens if not hundreds of similar behaviors that have to be completed more than once. And as code grows, is worked on by multiple developers, or just for the sake of speed, the same code gets copied or rewritten over and over again in different places.
Last week I finished up the first section of The Object Oriented PHP Masterclass. The class was great, and I learned about as much from my students as they learned from me. One of the most common questions I got from my students was “how do I make decisions about how to design my object oriented applications?” This question got me thinking about object oriented design.
The syntax of object oriented PHP is relatively straightforward…
In the second live session of my object oriented design class, The Object Oriented PHP Masterclass, I show my students domain modeling, both with slides and with a live coding demonstration.
In my demonstration, I show them how I break the single model they’ve been using into three component parts: a value object, a data layer object (usually that talks to the database), and a gateway object that stands between the other two.
All of us would prefer to work on code that we love. And all of us are faced with code code that we feel…well, not so warm and fuzzy about. Its the nature of our business.
Legacy code is everywhere. From code that’s just been around a long time to code that was rushed to completion years and years ago and never fixed, we all have to deal with things that are imperfect and challenging to deal with.