Thursday, July 30, 2009

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.

Tuesday, July 28, 2009

Friday, July 24, 2009

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?

Thursday, July 23, 2009

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.

Wednesday, July 22, 2009

Next Week’s Webinar – Unit Testing In An Organization

Note: Cross posted from The Typemock Insider Blog.

Permalink

Just a promo. We’ll have the official PR with links soon.

Next week Roy Osherove and I are going to discuss how to defy the odds and convince your organization to adopt unit testing. Yeah we know, we had it easy. We just said UT, and the entire organization adopted it. NOT.

In real life, there are many challenges. Your boss may object. Your team will cringe at “more work”. You know in your heart (and from our blog) that it’s the right thing to do. What can you do?

This is not a tech demo. It’s a talk about real life. We’ll share from our experience and we encourage people to come tell their tale. Yes, we’ll whine a little. But most of it will be positive actions. Things can you start doing right now, on your way to quality bliss. Fame and fortune follow, of course.

As before we’ll have two sessions next Wednesday (July 29th). The first one is 8am GMT, and the next at 3pm EDT.  So clean up your schedule, prepare a drink, and let’s share stories.

See you next week.

Monday, July 20, 2009

Richard Fennell’s Unit Testing SharePoint Presentation

Note: Cross posted from The Typemock Insider Blog.

Permalink

If the webinar’s not enough for you, Richard Fennell gave a presentation on the subject last week, and it’s a good one. Go take a look.

TDD takes years?

Sometimes it does. But with a supporting environment, like stated in the post, commited people around, lots of code and test review and quick feedback reporting loop it needs much less time.

The problem is finding these environments. If you’re lucky enough to stumble on such a workplace stay there. After that, you can create your own environment. his also takes years.

SharePoint Unit Testing Webinar on Our Site

Note: Cross posted from The Typemock Insider Blog.

Permalink

Well last week’s webinar is now on our site. You can watch the SharePoint Webinar as well as download the code examples. Thank for everyone who joined, and I hope more will do so in the next ones.

I had a lot of fun doing this, and we’re already working on the next webinar – how to successfully, and less painfully inject unit testing into your organization. Drugs not included.Watch this channel for updates.

Sunday, July 19, 2009

Is QTP Really Anti-Agile?

I have no experience with QTP. But I know a bit to answer why QTP is or is anti-agile:

1) No support for programming languages like Java, .Net so that it allows it to be used as an acceptance testing tool.

Having an acceptance test tool is very important for the team. QTP automates testing, making it favorable to an agile team.

2) VBSCript doesn’t help in everyone’s participation in the automation process, which is a key in agile projects.

Everyone’s? For example the product owner? If she knew JScript then it would be ok?

3) No IDE support : QTP’s IDE is no way near Ideal hence makes maintainable a tough battle.

Don’t know really. But I’ll get to the tool selection later.

4) NO support for standard IDE like eclipse

Yes, because no .Net projects are agile.

5) Multi browser support is limited

Yes, because all form-based apps are not really agile. Detect a pattern here?

6) Cant execute scripts on Linux and Mac platforms.

Yes, because Windows app… well, you know already.

7) No continuous integration support, makes it raelly tough to be used as an acceptance testing tool.

Maybe, but not all tools have to fit into an acceptance test tool belt.

8) And last but not the least : Bloody expensive ;)

Price for a tool which makes your life easier (or not) does not really impact it’s agility. I guess “Resharper” is not “agile”. Sheesh.

 

What does an “agile” tool look like?

Well, prepare yourself for a surprise – no such thing. Although some may argue that a whiteboard and sticky notes are agile.

A tool should fit into the process of development as neatly as possible, without causing friction. It should facilitate adding value to the product with a constant velocity for the long run. If it helps the process, cool. If it’s not, try something else. If it costs you, find if that ROI is bigger than one.

And then you can call it “agile”. You’ll probably be the only one calling it “agile”, but hey, you’re definition, not mine.

Sunday, July 12, 2009

Typemock Webinar on Jul-15 - Unit Testing SharePoint

Note: Cross posted from The Typemock Insider Blog.

Permalink

We’re starting a bi-weekly webinar. The first is on Wednesday, July 15th, and is going to be about unit testing SharePoint. We’re doing a repeat on the same day, so it’s going to be one for each hemisphere.

I encourage you to get one or two peers that don’t know about Isolator, and invite them to the webinar. If SharePoint is your thing, it’s the right time to start unit testing (if you haven’t already).

Here’s the complete text:

Unit testing SharePoint – The only way to do it

Join us for a Webinar on July 15

Typemock invites you to its ”Unit testing SharePoint – The only way to do it” live webinar on July 15th, where a special live demonstration will take place on how to unit test SharePoint with Isolator - the only tool today that unit tests SharePoint applications.
Developers who will attend this webinar, will realize how simple, easy and fast it is to unit test their SharePoint applications, release code with fewer bugs and spend less time on debugging.

This webinar will include:
• Guidance on what needs to be tested in when unit testing SharePoint.
• Different methods of dealing with the challenges of Unit testing SharePoint applications.
• How eliminating the need for a Database, just for the testing, helps to simplify the writing of unit tests.
• A demo on how to test Web-Parts and administration code.
• Q&A session

Here are the links for registration. We have space limited so sign up now.

1st seating registration:  8:00 AM - 9:00 AM GMT

2nd seating registration: 2:00 PM - 3:00 PM GMT 

See you all there!

Yet Another Racer Review

Note: Cross posted from The Typemock Insider Blog.

Permalink

And another Typemock Racer review emerges.

Thanks, Bill Craun! I really appreciate the time you put into the review.

Just to remind everyone, you can download Racer and find out what it can do for you.

Tuesday, July 7, 2009

Parameterized Tests and RowTests

Note: Cross posted from The Typemock Insider Blog.

Permalink

Mel Grubb talks about parameterized tests and why use it at all. He also raises the question whether having the ability to run parameterized tests can rule out usage of a framework. Personally, I think there are better ways to choose unit tests framework, but that’s not what this post about.

First, what are parameterized tests?

Regular tests, in NUnit, MSTest or other frameworks, are void methods that take no arguments. Parameterized tests are tests that certain frameworks (like Gallio) can run several times, each with a different set of input parameters and expected result.  MbUnit uses the attribute RowTest, because each row contained a set of input parameters and a result, like a list. (And if you’re familiar with Fit/Fitnesse, the table metaphor may remind you of this as well).

With different parameters, I can run the same code, and not need to copy/paste it. This looks like a great productivity boost. But like Mel said, you’re losing some readability of the tests. If you came back to the code 2 weeks, months or years and look at the code, you wouldn’t know what differentiates the 2nd from the 3rd row. They all look the same.

So what Mel suggests is doing some refactoring, and increasing the readability by naming the tests accordingly, which I agree whole heartedly with.

But I’ll go a step further. Which test would you like to debug, if it broke? The one with the descriptive name that tests a single scenario, or the one with the laundry list of arguments? I’d go with the first.

One more thing: Now you can use the parameter in the test itself. Instead of arg1, you can now send to the tested method arg1*2. This starts to smell, you’re actually putting logic into the test. So, especially for beginners, or other people who would like to cut corners, I wouldn’t recommend using it.

Let’s say I have a component that does authentication. You give it a name and password, and it gives you back a yes/no result. For all the specific criteria I’d write specific and named tests: name is null, password is longer than 6 characters, password contains alphanumeric characters. Basically, if I can characterize it in words, I’ll write a unit test for that.

Now if I have a batch of hundreds of collected names and passwords, that I just want to make sure that pass authentication, I might want to write a parameterized tests, or just loop through all the list and assert the result. That’s in addition to the other tests I’ve already written.

By the way, if one of those breaks, I’d write a specific test for that as well. I’d recognize the case of failure, and characterize it. So the next time I come across, a case like that, I can debug more quickly.

Parameterized tests are nice. But do yourself a favor, for unit tests stick to the basics.

Monday, July 6, 2009

Unit Tests Myth Busting

Note: Cross posted from The Typemock Insider Blog.

Permalink

Arjan Einbu spills the beans on his experience with unit testing, busting one myth after the other. Like the “I don’t have time” excuse, if you’ve used any of these excuses, better find a new one. Scratch that, write a test.

And about the one where management doesn’t buy into it? Go guerrilla and do it behind their backs. You might not get the pat on the back, but they’ll be busy blaming all the other developers for breaking the app, while you’ll be gloating about your perfect code.

Sunday, July 5, 2009

Eran Ruso on a Good Build Machine

It’s a nice post, that covers the essentials, in addition to what I posted before.

A nice plus would be the ability to run integration tests as well. The build server should be able to at least run nightly, and in such cases, why stick to just unit tests?

The ideal is to build with every check-in, including running the unit tests, for getting quick feedback.. Then on a timely basis, run the integration tests as well. This way you’re covered.

Eric Shupps on SharePoint, TDD and Unit Testing

Note: Cross posted from The Typemock Insider Blog.

Permalink

A while ago, Eric Shupps wrote about TDD and SharePoint development. His follow up post is really a good read, because rather concentrating on the technique (TDD or Test After), he’s concentrating on why we do unit tests in the first place: Making better code, for less bugs and shortening development cycles.

And I like this quote:

"In fact, I would argue that, due to the complexity of the SharePoint object model, the various undocumented and often erratic behaviors, and the level of skill required to effectively troubleshoot and optimize such code, Unit testing has more value in a SharePoint context than in any other.”

Yes, you can replace SharePoint with your favorite technology and it’s still works…

Solving Problems with Isolator – Windows Service Interception

Note: Cross posted from The Typemock Insider Blog.

Permalink

At the same day I posted about different usages of Isolator in the real world, that are not just regular faking, Travis Illig contacted me about an experiment he’s doing, which obviously succeeded.

Travis, a Typemock MVP, used Isolator to change the behavior of a single method inside 3rd party code, running in a Windows service that was giving him pain. The pain was removed by allowing Isolator to run inside the production code, intercept the offending call, and redirect it to another implementation. Now, how cool is that?

I’ve discussed with Travis other ways to intercept and modify calls. The first one Travis suggested is using a Swap.AllInstances of the offending type and then using a WhenCalled-DoInstead combo, to intercept the call and execute another piece of code instead.

The second option is redirecting the calls to another object, as Travis solution does. In this case, you redirect calls from one object to another. Only methods that have the same signature get redirected. All others are executed on the original object.

The final option is using CThru. With CThru you specify all the method calls you want to intercept, and then implement an event handler that is invoked when the method is intercepted.

For all these to work, you need the Isolator engine to run, and that’s why the environment variables are set. Basically, you can run TMockRunner and do the same thing, although it does get a little heavy when handling Windows services.

Well done Travis! Another reminder that innovation comes from everywhere – when people use a tool differently than what it was intended for, great things can happen.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More