Links
·
RSS Feed
Popular Pages
 |
 |
...It would be really nice if, as an industry, we could stop being such a bunch of screwed-up clowns and start living up to our potential. Ship It! is one of the things that could help, if only tho...
-Mike Gunderloy |
 |
Quoting Watts Humphrey, "Developers are caught in a victim's mentality." We never think it's our fault, it's always somebody else's.
-Jared Richardson |
|
Do it right from day one or you never will
-Andy Hunt |
|
|
|
|
(Jul 13)
Quite often (and again very recently) I've run into a simple, but frustrating, misunderstanding. I'll often come to work with a team, evaluate their current state, and chart a path for them to move forward. For many of the teams I encounter, this ends up starting with continuous integration and test automation (along with a few other practices).
And I'm repeatedly finding that some developers, but nearly all managers, assume that I'm focusing on QA, or worse, that I'm in a QA role.
It's not that being equated with QA is bad. It's a compliment if you've known some of the testers I've worked alongside. The problem is with the fundamental misunderstanding about the role of automated testing. Automated testing isn't something you hand off to someone else; it's a function of your job if you're a senior software developer (or ever hope to be).
A sure sign of an immature or prima donna developer is the thought that writing automated tests are beneath them, and that someone else should write those test for them. Having someone else write your tests for you is what I call being a software pooper scooper. You're agreeing to follow someone else around and clean up their mess.
What's that you say? There is no mess? Really? If you think that you, or your team, can write tests with no bugs, then you're deluded. You're simply fooling yourself, but not the people who use your code.
Writing software is difficult. There are so many moving parts and we have to line them all up perfectly. Clicking through by hand isn't cost effective, or especially repeatable. If you want to KNOW that your code runs as you intended for it to run, then wrap it with an automated test. There's a small learning curve, but not much of one. Once you've written a handful, you'll find they take very little time at all to create. In fact, compared to sitting at a keyboard and debugging for an hour or two, you'll find writing an automated test takes no time at all.
And that's when you'll be on the road to being a real senior software developer.
Here are a few links for those of you just getting started:
My Junit tutorial
TDD for Embedded C
An Introduction to GTest
An NUnit Tutorial
Category: Agile
|
|
|
|
|
