Almost every day in the "Answers" section of LinkedIn asking about automated testing of a web page. This one is typical : "What is a good Open source / Free test automation acceptance and regression tool for dot net applications?".

My usual response is "We've had great success using Watir for automated testing in IE. It's built in Ruby, so there may be a bit of a learning curve. Still, there are excellent tools out there to record and build scripts."

Watir, short for "Web Application Testing in Ruby", is a free, open-source testing library for the Ruby language.  It's very easy to use, and extremely powerful.  The Watir engine automates an instance of Internet Explorer (or Firefox, if you use Firewatir),  and gives you easy access to the page content. It's a real lifesaver when dealing with testing multiple page forms.

A simple example in Watir to test my blog page:

require "watir"

# open the IE browser

ie = Watir::IE.new 

ie.goto "http://danimal.acsysinteractive.com"

if ie.text.include? "Musings on web development"  
puts "  Test Passed. Found the test string: 'Musings on web development"
else
puts "  Test Failed! Could not find: 'Musings on web development'." 
end 

Obviously, that's a basic example, but it's very easy to click buttons, follow links, and the like. However, for longer tests you don't really want to hand-write all of the Ruby code. That's where a script recorder is very useful. With a recorder such as Watir Recorder, you can simply browse a site in the application to record the script. Save it as a .rb file and you can run it over and over again.

Frequent testing of your GUI with Watir, and unit testing your business logic can go a long way toward quality code. If you're not using something like Watir, why not check it out?

Did you ever wonder how you can do TDD with Linq to SQL, since there are no IOC interfaces to play with? Well, neither did I, quite honestly. However, Matt over at the Wayward Web Log did, and he puzzled out a way to do it. It's pretty zany stuff -- he plays with remoting and reflection to pull it off -- but it looks like it would work. Not an article for the faint of heart, but good to have in your toolbox if you need it.

 

Turns out I'll be spending the second week in July going for Biztalk training. Though the subject matter may be a bit dry, I think it's going to be an excellent course.

Biztalk, for those of you not in the know, is a Microsoft server that's designed for application integration. It's used to transfer data between disparate systems, through XML-based messaging. The central Biztalk engine has a few major components:

• a Messaging component, which allows communication across a wide range of software. It offers pluggable adapters for different types of communication, such as FTP, STMP/POP, web services, etc.
• an Orchastration component, which allows the creation and execution of business processes in a graphical environment.
• a business rules engine, so you can change business rules on the fly (as opposed to compiling and deploying a .net assembly)
• an enterprise single-sign on (SSO) tool

We're going to be using Biztalk a lot in our upcoming SOA projects, so I'm thrilled to be able to get this training. Better yet, it's in Waltham, MA, so after class I can take a trip to Jacob Wirth's for a pint of Jake's Dark!
 

Jeff Atwood has a post today talking about coding BASIC on old-school computers (specifically, the Atari 2600). It really made me nostalgic for when I got started programming on my Commodore Vic 20. Ahh, what a system that was.

It was a great machine. It had a whopping 5 K of memory (yes, Kilobytes, not megabytes), and the "operating system" was Basi, burned onto the ROM. About 1.2K of the system memory was taken up by basic, so you had 3.8 k left for programs. Once you typed in your code, you could save it to the external tape drive (a cassette recorder). 3.8 K took around a half hour to write to tape.

I spent hours and hours on that little machine, putting it through its paces. I played through the Scott Adams adventure games, and the family still chuckes at the magic words "Say Yoho" from Pirate Adventure.  I learned basic, and just about memorized memory locations for poke and peek. That little machine started me on my way to geekdom.

 

I was overjoyed to find  the Vic 20 programming manual online. Check it out, nostalgic geeks!

Joel Spolsky and Jeff Atwood are my favorite technical bloggers hands down. They write clear, cogent, and frequently amusing posts that really get me thinking. They're so good, and so prominent in the community, that if an interviewee can't talk about their stuff I tend to grade them down. Hell, Jeff and Joel are largely responsible for the existance of this blog.

That's why I'm so glad to hear that they're working together on a new project, called StackOverflow.com. In short, stackoverflow.com will be a free and open community for developers to ask and answer questions. Per Jeff it'll be "sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit." Sounds like a great project, and should be really useful to the developer community.

So far all they have on the site is a podcast talking about the vision. I look forward to seeing what comes down the road.

Hrmm, I wonder if the site will be built  "in a proprietary language they created themselves"?

We're nearing the close of a very interesting assignment. We were hired by a large securities broker/dealer to develop a five year digital strategy, vision, roadmap, and tactical plan. It's part of a larger effort to revamp their public web site, recruiting site, advisor extranet, and various web portals. My part of the project was taking part in the tech assessment, where we analyzed their current technical environment to see how it would fit in with the overall strategy.

It was a fascinating project. We started out by gathering some basic information, then flew down for 2.5 days of interviews on site. We got to dig deep on a number of areas, such as their long-term internal initiatives, pain points, advisor experience, and the like. We took those notes back and did some hardcode analysis on them. The end result was a 45-page document that we just presented to the CIO this afternoon. I think he was pleased.

One of the deep dives we did was around content management and Microsoft SharePoint. Our final recommendations were that SharePoint is excellent as an intranet out of the box, but if you want to extend it with custom functionality or look and feel then you're in for some serious pain. Because of that, for their extranet, public site, recruiting sites, and portals, we recommended Ektron.

Other recommendations:

Implement a service-oriented architecture: The client has numerous data feeds to and from customers, partners, and suppliers. The obvious solution is an SOA, and they went into the process expecting that recommendation. I got to do some good research on BizTalk as an ESB, though.

Authorization and Authentication: They're currently using a home-grown forms authentication scheme, with the usernames and passwords stored (unencrypted) in a database table. Not the most secure solution, I'm thinking. We recommended using the asp.net membership with AD, though encrypted database info would also be ok.

Web 2.0/Social Networking: If there's any site that's screaming for some social networking, it's their advisor extranet. They have a big pool of talented financial advisors willing and able to share information, but no way to do so. They also have product managers -- people who run mutual funds, for example -- who would joyfully provide valuable content. Hook the two groups together and I can great synergy. With the new social networking functionality of Ektron, it'd be really easy to integrate.

Mobile is another no-brainer. Advisors don't want to sit there at their desks emailing powerpoints to their clients. They want to be able to get their information at any time, from anywhere. Add some mobile functionality to the site and an advisor can get a portfolio summary for his client from his cell phone, as they're playing a round of golf.

Development Methodologies: they have a really good dev team, with years of industry experience and deep product knowlege. Better still, their code toads get to actually code, instead of spending most of their time in meetings. However, they have no formal development methodologies -- a client requests something, it gets assigned to a developer or two, and they just crank it out. Cowboy coding at it's best, right? We recommended Agile development, and I think it'd work well for them.

Other recommendations were pretty basic: host your sites externally for DR purposes, use a solid SSO package, etc. -- nothing exciting, but valuable nonetheless.

All in all it was an interesting experience. I got to do some deep research on technologies that interested me, and provided what I think was useful information to the client. I hope to get more of such assignments in the future.