By Any Other Name

Note: Cross posted from The Typemock Insider Blog.

Permalink

I’ve read Mark Needham’s post and Julio Maia’s post on impersonators. They are a good read, by the way. And they reminded me of habit we developers have that helps us shoot ourselves in the foot.

Names. Where would be without them? How can we get along without verbally differentiating between this thing, and that other thing, which is similar, but not that similar?

I always come back to patterns as an example. Because they have names, it increases the communication level, since we don’t want to describe and re-describe everything over and over again. When I say Visitor, I assume that people know what I’m talking about. Smart ones, of course, I don’t hang around with other kinds.

But we can go too far with it. Mocks, stubs, fakes, test doubles, impersonator (which is a self-initializing test double, if you didn’t know), and probably other sub-types. Sure there’s a difference, Martin Fowler said so.

With all due respect to Martin (I worship the Refactoring book), this is doing more harm than good. Categorizing is ok, but most people don’t have all the nuances in their heads. When they begin to read about unit testing, they find out there’s a big pile of things they need to learn. When I see a great pile of reading  material in front of me, I’d probably won’t read it. I might discard the subject altogether since it’s obviously complex, and I don’t want to deal with it.

Yes, it’s a jargon. And for the few that can spend hours discussing the specifics of when to use what, it’s very impressing. But for making the breakthrough and getting people on board for your cause, simplicity is key.

Let’s use a simple language. When we need the little details, we’ll call, we promise.

So dear readers: Which ones do you use?

Plug Your Own Leak

Note: Cross posted from The Typemock Insider Blog.

Permalink

This week I met a very clever developer. I know that when I say “clever'”, it usually leads to a horror story. Not this time. This guy is smart, built a very smart application. He put a very strong emphasis on good OO principals. Worked against interfaces. And he wrote his own hand-rolled mocks.

I wrote before on the cost of using hand-rolled mocks and why you need an isolation framework. It’s a terrible waste of time, code, and a maintenance debt you carry for the application’s lifetime. Without proper attention it can get out of control, when you start putting if-then implementation in the mocks, to fit the logic in the code. That’s when you have a horror story.

And then I read Oren’s post, reminding me that we shouldn’t steal from our customers. It’s also true when our customers are our employers or ourselves. There’s no excuse for writing boiler plate code, including hand rolled mocks. There are already tools to help you.

There’s a leak in the process. Plug it.

Use the right tool for the job.

A Couple of Webinars After

So far I’ve done 4 webinars, and I tell you – I like it.

Still have a lot to learn. The one I did with Roy was different, and I’ve learned a lot just by preparing to the webinar (less than an hour before…). I still need to get the hang of talking to a crowd, while still maintaining the direct 1-on-1 I have while doing demos.

I think of doing just Q&A webinars, along with ones covering different topics.

Few things that were better this time around:

• No breakage like last time.
• more people attending. In the 2nd one yesterday we had almost 70 people, which is a record so far, and we’ve done some basic marketing. What we’re doing seems to work. It’s catching on.
• We need to be more specific about what we’re inviting people to. People came yesterday expecting a technical demo, and we failed them
• I need more automation in thank you’s and welcome’s and stuff. I want to see what happens after this thank you note.
• I like the reports GoToWebinar gives me. I like data. Give me numbers. Now give me more.

It catches on. And this is a great way for building community. We’ll see what happens with a few more.

And if somehow you’ve missed the webinar, here’s the Unit testing SharePoint one, and here’s the unit testing in an organization.

InfoQ - Guidelines for better unit testing

InfoQ has a treasure trove of good advice.

Go read it.

A Couple of Isolator Tricks

Note: Cross posted from The Typemock Insider Blog.

Permalink

Soon Hui Ngu wrote on how to use DoInstead for verifying argument in a method. Another option, by the way is to use a custom checker with Verify.NonPublic APIs.

And Ryan Rivest shows how to use a queue to set up different fake objects of the same type, and then use Swap.NextInstance.

Cool stuff, keep it coming, guys!

Got any other cool ideas you want to share?

No Communities for Testers?

This is a good question. For two reasons. The first is this is true at all, which I’m not sure. The second is the comparison to developers.

As a developer and manager of both kinds of teams, I remember being more open and hearing more about dev meetings in user groups, and not much on the tester side (although there were some). However, it was more QA oriented (formal, ISO, things like that, rather than new methodology to test).

Do developers tend to share more? Or is it the type of craft that’s easy to communicate? All the idioms are already in place: WCF, C#, patterns, design. And every developers know them. Is it not like that in the tester community?

Are Sensible Arguments Enough?

Note: Cross posted from The Typemock Insider Blog.

Permalink

Yesterday we had our weekly company meeting, and we discussed the value we offer, as well as the challenges we face in explaining it. This morning I read this post about advantages of TDD and testing early, on the Google testing blog (There are smart people working at Google), as well as the comments. Somehow, the stars aligned and both connected on the same day (or so).

I agree whole-heartedly with what Shyam Seshadri wrote – the arguments are relevant. They make sense. Or do they? Well, the secret is, they make sense to the converted.

Because after you’ve read the post (and comments), go back up, and read the intro – Shyam is still frustrated that he cannot convince his peers to do unit testing, even though he’s using these sound arguments. Obviously, they are not not enough.

In the next webinar, we’re going to discuss some of the challenges, and methods to deal with them. If you feel the frustration – it’s good. It means you care about your code, product and your professionalism. Let’s direct it to the correct channel (and I’m not talking about violence. This time.).

I’ll post more after the webcast. Join us and share the things you do to get people on board.