So you want to try Test Driven Development — great! But that requires expressing the intent of the code-to-be in automated tests. Where should you start if you don’t even know what the code should do? What should you do if you’re not confident about a particular approach?
You drive a spike through it!
To start my “Marvel Browser” iOS TDD sample app, I want to begin by making a network call to the Marvel API. If I knew what I was doing, I would start the 3-step “TDD waltz” of writing a single failing test, then writing the simplest code that passes, then refactoring.
But there are two roadblocks keeping me from writing my first test:
objc.io is a monthly online magazine, with an editorial team. Each issue focuses on a particular subject, and Issue #15 is about Testing. I’m honored to be a contributor with my article “Dependency Injection”.
My article refers to two books I highly recommend:
Question: Do you have any comments about my Dependency Injection article, or any of the other Testing issue articles? Leave a comment below.
In the spirit of Dr. Seuss, this video begins,
When a coder sits down to start banging out code,
the first thing to start crowding his cognitive load
is whether his program will do what it should.
“Correctness,” he says, “is what makes my code good.”
But it goes on to explain why clean, readable code matters, and ways to get there…
For such a short video, it has a lot of meat. And I love that last sentence! I really should get a copy of the Kent Beck book that inspired it, Implementation Patterns.
Question: What did you think of the video? Leave a comment below.
Slogging through code is what we do for a living. What would you give to be able to improve your existing codebase?
The Refactoring book completely changed the way I code.
In 2001 while searching for information on design patterns, I discovered the original wiki, and stumbled on Extreme Programming. This led me to a software development conference in 2002 called SD West. There I attended a session by Martin Fowler, and knew that I had to pick up his Refactoring book that day.
How could I resist a book that promised to teach me about “improving the design of existing code”?
Many years later, I find the term “refactoring” being thrown around in the workplace, at several software companies. Programmers and managers often talk about “refactoring,” when they usually just mean “rewriting.” I’ve seen nightmares brought about by so-called “refactoring” that introduced so many defects, it compromised the product ship date.
The Refactoring book, however, teaches a disciplined methodology of changing code in small steps, with automated verification of each step.