Another TDD Convert

This has been one of the craziest weeks in my IT career, but perhaps one good thing has become of it.

Before and after I became Tech Lead, I’ve been trying to convince everyone that Test-driven Development is really The Way.  But I still heard things like, “I have the the code done, now I have to write the tests.”  So, really, my message wasn’t getting through.

This week was Panic Mode in a big way.  Long story, but me and another guy worked all day and three to four hours at night, and an offshore resource worked all our night (his day) and three or four hours in his night.  I’m not saying that it was a job well done nor that I relished it, but one good thing came out of it . . . On Thursday, my on-shore cohort said, “You know, Mike, writing the tests first is really a good thing!  Now I know that my code works every time!”  And we demonstrated problems with each others logic via unit tests and then we knew what to fix.

He told me this several times during the day, but I knew he was a True Believer when I heard him tell our off-shore guy, “Yeah, I know you fixed it, but you didn’t make any Junits for it.”

Now he sounds like me!

A Continuous Integration Addict

I have to admit — I’m addicted to continuous integration.

When I’m deep in coding and finally commit my work, I generally go over to our build server and see the status. If it’s not going to build for a few a long while, I generally start it manually.

Why do I do this?  I like to see the coverage report (did I make it better?  Or did I make things worse?) . I also like to see how many unit tests I created (on the subproject I was working on today, it started out at 88 and went to an even 100.  Seemed like a good place to start).

Is this normal? Or am I a strange addict?

Why Are GUI Testers So Bad?

I’m not sure that everyone is familiar with GUI Testers, so let me describe them to you: You have it record your interactions with a Windows application, have it check some fields for you, and you save it. Next time it validates that thing still are the same as they were before. Sounds simple, right?

Of course, that’s in a dream-world. Reality is very different.

In my last position, I was a developer with the job title “QA Engineer” and I started using TestPartner from Compuware. I found it extraordinarily difficult to use: I would have it save my actions and have it immediately play it back. But things would go wrong and it wouldn’t work. Why? I was never sure — it couldn’t find a menu, it couldn’t recognize a right-click, some little thing changed and things just blew up. I never figured out how to tame it’s wildness, but that was okay — I figured that TestPartner was just tempermental.

In my current position I’m a Java Developer and we have to write some scripts using WinRunner from Mercury/HP. Since I’ve used GUI Testers before, I was elected to head it up. I thought WinRunner had to be a lot better than TestPartner but I was wrong. Oh, in some ways it’s better, but in some ways it’s worse. The warts are a lot different, but they are still warts. And, yes, I can record an action and that action won’t play back. Different system, same problem.

I’m not going to compare them, but I will list out what I think the biggest warts these two applications have in common, besides the example I cited above:

• They don’t store their scripts in text files. One stores everything in a SQL database (!!!) and the other stores things in a directory (which has a text file called “script” but also has lots of data files, etc.) This forces you to use their editor. And forget grep and other ways to quickly find a useful code snippet.
• The documentation is horrible. It’s hard to find something useful, it’s hard to find a simple reference, and the examples are less than useless.
• Good ideas that are half-way implemented. One of the apps above signifies that you can use regular expressions to find the window names. That is a good idea, but it takes a lot of reading to find their long-winded prose explanation of regular expressions and then you find out that it’s only a small subset anyway. Example: in their regular expression syntax * will repeat the preceding expression 1-many times. Oh, and there is no + or ? characters or anything like them.
• It’s hard to have a common function library. One has you use shared modules, which are shared for all scripts within that category (again, another good idea half-way implemented). The other has you “compile” your functions, and then in your scripts you have to click the button to add it in. If you change your “compiled” functions, you have to manually remove it and add it again to each script. Or perhaps just restart. Either one is undesireable.

Maybe my problem is that I’m a developer living in testing world. The mindsets of a good tester and a good developer are similar, but by no means the same. Maybe these tools are good for someone with a testing mindset. If these were developer platforms, no one would use them. That said, I think the reality is that testing applications lag greatly behind developer applications.

VMWare Server

I’ve had the pleasure of playing a little with VMWare Server late last week as well as most of this week.  I’ve only used one virtual machine (Windows 2003) but I have to say that I’m impressed – much nicer than VirtualPC.  And it’s free!!

Setting up a virtual machine is easy but that’s not the coolest part.  The coolest part is that you can start the VM in the console on one machine and then shut down the console.  But the virtual machine is still running!!  I can use another VMWare Server console on the same machine or a different one and get on the same instance.  This is especially useful when you are using the VM as a server — you don’t need to look at it all the time.  Just unattach it (my word) and then re-attach it when you need to.

This is a highly-recommended piece of technology.  Did I mention that it’s free?

On Trac

One of the most important things in testing is keeping track of the defects you find.  That way, everything is in one in place, and you can easily pass issues back and forth.  This week I’ve been evaluating Trac and I have to say that I’m impressed, and I haven’t gotten to all the functionality yet.

Trac is a combination wiki, defect tracker, and svn watcher.  I’ve setup and used wikis and Bugzilla before, but the combination is really quite ingenious– you can have a wiki-link from inside an issue summary or in a case.  That wiki link could be to anything — more detailed docs, a setup document.  I didn’t mess with the wiki very much or the svn watcher (because our svn respository isn’t up yet) but I spent a lot of time with the ticketing system (i.e. defect tracker).

I’ve setup and used Bugzilla before.  And it’s nice, but building a query can be overwelming and you can’t build your own reports.  Adding custom fields is a pain as well.  But Trac makes all of this easy.  You can build reports going against their database,  even though they are deprecating it.  Too bad — I understand the reason, but I was able to build reports with it that I couldn’t do with the query module.  Oh yeah, the query module – it’s what they recommend to use now. You choose new filters and it just drops down.  Pretty easy to build an ad-hoc query, and you can easily create links to save your query.

Make custom fields is the easiest part — you just put them in the trac.ini file and Trac loads them automagically.  You can make them drop-downs or text fields, etc., depending on how you put it in the .ini file.

So if you are thinking about getting a tracking system setup, you really should give it a look.