May 2008 Archives

Towards a Testing Vocabulary

| Comments

I know I’m probably late to the game, but I just found a great breakdown of kinds of test doubles.

There are a lot of terms floating around when it comes to automated testing:

  • Mock Objects
  • Fakes
  • Dummies
  • etc
This isn’t a big deal when you first write tests. As your testing becomes more advanced, things get complicated. Eventually confusion sets in when someone goes to use your mock object and you have to tell them it only works for a specific test, or vice versa.

Martin Fowler mentions testing vocabulary in one of his essays, and refers to terminology from Gerard Meszaros. I did a little digging, and found that Gerard authored (among other things) a neat chart on the aforementioned page that shows how different kinds of test doubles compare in their behavior, along with some examples.

I have a healthy respect for what the folks at Yahoo! have been up to . Projects like Pipes and YUI show they’re committed to not being followers or Google wannabe’s.

So I was happy to see the Yahoo! Developer Network Blog announce a sneak preview of BrowserPlus, their new-fangled platform for squeezing even more out of the humble web client.

I tinkered around with some of the demos, and was impressed with the snazz factor. The installation, however, is still probably too much for the casual web user. My dad unplugs his cable modem after every use. I seriously doubt he’s going to be cool with a site calling for an installation of C++ 2005.

Paranoia aside, I’m excited that people are still trying hard to find new an better ways to get more out of the web. I’ll see if I have some time this week and follow up with a more thorough review.

Ok. You shouldn’t steal Pragmatic Version Control With Subversion, but you definitely should buy it. I was reading an article at NOOP about what school doesn’t teach you about source control, and felt they left this very handy resource off their list of must-haves ( theirs includes Version Control for Multiple Agile Teams and The Importance of Branching Models (PDF) ).

Pragmatic Version Control With Subversion is a great for to people who fear Subversion and CVS. It includes exactly the information you need to get rolling without extra confusing fluff. It’s all about getting your stuff done.

If you have a team member who is new to svn, or if you can handle the basics but don’t know how to merge changes from a prior revision or branch, this book is for you.

“Send me your dev estimate.”

This directive is made by project managers probably 30 times a week. I’ve found that shooting off a quick email like “ten days” is asking for trouble.

The problem is that PM’s are interested in dates, and little else. They want your estimate so they can plan the project, so they can tell their boss when to expect the launch.

They don’t care about the breakdown of your tasks, or how much time each contributed. They just want to get that big red X put on the calendar.

So, if your dev estimate is “ten days”, the PM will happily count 10 business days off the calendar, draw the big red X, and make that the dev complete day. They probably won’t ask if you factored in your availability, code review time, or your time for supporting the testing team. They’re just happy to get a number.

Of course, things get ugly when it’s ten days later, and you’re not dev complete because you had two other projects to work on, and you had to wait on the DBA’s to dial up the new schema you needed.

To avoid these nasty under-communications, I follow a sort of template for estimating. Here are the main points I always try to cover, followed by a sample estimate email message I might send to a PM.

Don’t wait until the end of a project to write tests. It doesn’t work.

Writing tests is never urgent, but it is very important. Devotees of Stephen Covey will tell you this puts it smack in the middle of quadrant two: things that are important but not urgent.

Quadrant one, urgent and important things, prevent any other work from being done. Unfortunately, the final stages of any project are chock full of urgent and important things, like fixing bugs, building deployment packages, scheduling rollouts, and other fun. All these are important and urgent. If you haven’t written automated tests at this point, don’t start.

No manager will ever tell you, “Sure, we’ll delay the launch by a week so you can write some code that won’t ever be executed in production and has no bearing on the project making it out of QA”.

So, if automated testing lives in quadrant two (it does), and that no real quadrant two work is possible at the end of a project (it isn’t), you need to write your tests early, when quadrant two is in full effect, at the beginning of the project.

I’m not saying you need to do test driven development. That’s hard. All I’m saying is that it’s important that tests keep pace with code. Get in the habit of running coverage tools when you finish modules, and write tests before moving on.

If you do find yourself at the end of the project with no tests, don’t panic. You’re not a bad person. You’re not a bad programmer. You just didn’t write tests. Don’t try to write them all at the end. You’ll only get frustrated and stressed out.

Finish the project, fix any last-minute bugs, and deploy. After that you’ll be back into quadrant two, and you can write all the tests you missed the first time around.

Use the <del> tag to indicate removed content. This is semantically correct, and most browsers render it as a strikethrough.

Often the <ins> tag goes somewhere nearby, to indicate the new content that replaces the old. The W3C offers this example in the ins and del section of the the HTML 4 spec:

  A Sheriff can employ <del>3</del><ins>5</ins> deputies.
Which shows up in the browser as:

  A Sheriff can employ 35 deputies.

Today I found myself in need of a strikethrough, and the search results I got weren’t very helpful, so I wanted to get this posted for any other lost souls out there. One final, subtle point is that del should be used when you actually are removing content, and not just to get a strikethrough, though I’m hard-pressed to come up with any interpretation of the strike other than “removed”.

Looking back on my career in software, I realize how idiotic it was for someone to throw me straight into building brand new systems. I had no clue what I was doing. School armed me with plenty of basic know-how and theory, but that doesn’t cut a whole ‘lotta ice in the professional world.

I spent my first year building applications; wasting my time and writing unmaintainable code. Then I was lucky enough to be put on production support for a large email system for the better part of a year. This was the single most educational experience of my career.

Production support forces you to deal will all the crap that others have slung. You encounter cryptic config files, no config files, bad error messaging, and poor maintainability. You learn about evil.

That’s why I think newbs should start out doing support. Yes, it’s a pain in the ass. No, it’s not sexy. Yes, you will learn a ton. Most importantly, you will learn the pain points of a deployed system, and gain a healthy respect for maintainability.

Yes, CSS is the greatest single advance since electricity itself. A self-respecting web developer would never admit to any deficiency in this core skill. Luckily, I am not that developer. I am sub-awesome at styling pages: box models, margins, browser quirks, quirks mode. Sheesh.

 Instead, I cheat on CSS, and on the user interface in general. I find lots of places to use simple but powerful tools to make good stuff.

One of my favorites is the Web Developer’s Handbook. It’s a huge listing of links to CSS tips and tricks, along with other interface stuff like color palettes and rounded corner generators. It doesn’t have everything, but it’s got a lot. Chances are good they have a link to what I need when I encounter something I don’t know how to do, which is often.

I’ve done a pair of sites [1,2] using SimpleViewer, a sweet Flash thingy that makes great looking galleries. It’s a wonderful example of how a product can market itself. There are a lot of configurations, but the default setup is perfect for 99% of what people need in a gallery. They also have scripts for crunching thumbs from your images. After that, you just point SimpleViewer at your image directory, and you’ve got a slick gallery. Basically, an image folder + SimpleViewer equals sweetness.

 It’s way better to have a product that comes out of the box ready to go, rather than one with all kinds of neato features, but that you need to configure from the ground up.

I used the pro version for one of the sites, so I could resize the thumbs and play with positioning. Even the ActionScript config is well-documented and easy to use.

Cobbler’s children have no shoes, and Code Softly is no exceptions. Comments here have been broken. You’d think that given the number of Movable Type sites I’ve rigged and maintain (Coolfer, Information Leafblower, and others), that I’d have the hang of things. But of course that’s not the case.

It turns out that Movable Type likes to keep all cgi script references relative to where the MT install is, and not where the published pages are. So, the comment links in the CS subdomain were pointing to nothing.

I thought about doing some mod_rewrite magic, but that stuff looks too much like regular expressions for my taste (I distrust anything with more punctuation than letters), so I just copied the whole cgi directory from my web root over to the subdomain, and poof, problem solved. I rule.

Comment away, friends.

I’ve started thinking about a set of phenomena I’ve termed “meeting smells”. These are like code smells, except they happen during meetings. If you notice one, it’s likely something is going awry with your get-together. Feel free to send me the smells you’ve witnessed, and I’ll add them to the list.

To start things off, here are three phrases that, when uttered, are almost a sure sign your requirements meeting has taken a turn for the worse.

  1. Table

“We can make a new table in the database to store this”

Software engineers LOVE this one. Give us a hard problem, and our brains dart to the database like it’s a digital comfort blanket.

This is because we often think of solutions as “starting at the database”. This is bad because (say it with me)… the database is NOT the application. The details of the database like table structure, are part of development. If you aren’t slinging code, you shouldn’t be talking tables.

  • We WIll
  • We will be responsible for the reporting piece of the app.”

    Make no assumptions about which team will be doing each part of the work. If one system has handled a particular kind of task in the past, there’s no reason to assume it’s the best thing to do the job this time.

  • It Will Be Easy
  • “Oh yeah, we do LDAP authentication on our sites now, so it will be easy to do the same on this application.”

    If you haven’t yet eaten these words, give it time. This is the core of missed deadlines, scope creep, cholera, and lots of other bad stuff. Something seems simple at first, but ends up way complicated.

    Once you utter the E-word, everyone assumes that “easy” means “instant”, and that there is absolute certainty the feature will be built. You’re setting yourself up for failure. Ego kicks in and you end up taking tons of time to build the “easy” feature that has become a beast of complexity, and steals time from other features.