Unit Tests

Earlier this week at Passageways we added a new member to the development team, Rajini. She joins us from the great [big] state of Texas and will be working as our new Quality Assurance person. But since it's been about six months since we had a dedicated QA, the developers started to take matters into their own hands *cue scary 1950's horror music*!

It's not really all that scary, and the solution we came up with makes for higher quality code both short term and in the long term when doing regression testing. What we've added is unit testing. In the past we've done manual testing exclusively, meaning we have a slightly glorified MS Word Document and a tester reads the instructions as she follows along clicking around the portal. These still work great and we haven't abandoned them. The unit test is different because it can be automated, and thus doesn't require a human to be present.

At the moment we're utilizing the unit test feature of VisualStudio 2005 Team Edition. I like it a lot because it integrates nicely with my developer environment. I can attach to the asp.net process and use line breaks to see what's going on in the test and if my newly written code is going to pass or not. What's frustrating is that I can't get it to automatically attach when I run the tests in debug mode, so I have to be quick. Also, if I bail out of a debugged test half way, then I have to go clean up my web.config file so that I can run the tests again. So it's not without its own share of wonkiness, but nothing that can't be overcome by a little practice.

I will also add that unit tests, while still in the tedious category, are a lot more fun to write as a developer than a long step-by-step word document because it's actually code. Presently, we're using the unit tests to check input and output of methods relating to the API, so basically the public methods that ya'll can hook in to - yes, I said "ya'll". Side-effects of methods (such as changing an object property, interacting with the file system) are still being tested via manual tests.

Side-effects of working as an employee at Passageways are still untested, but seems to result in high intakes of caffeine ;-)

Portal Message Tutorial

In this tutorial we'll be covering how to use the PortalMessage web control from the Portal Framework (PortalFX). This little jewel is how we standardize the messages presented to users of the portal; everything from success messages to "Hey! Something blew up!" can be shown using the PortalMessage control. So let's get started.

Example of the PortalMessage control being used to show an error:



First, you'll want to add a reference to the file Passageways.WebControls.dll. If you're using VisualStudio you can simply right click on the References folder of your project, then click "Add Reference". Click the "Browse" tab and locate the file. Click "Ok" when you've got it selected.

Next, you'll want to declare the control in your .aspx page, to do that you'll need to register a TagPrefix so it knows where to get the control from:

<%@ Register TagPrefix="PW" Namespace="Passageways.WebControls" Assembly="Passageways.WebControls" %>

Then, go ahead and declare the PortalMessage control where you want it to be displayed in your .aspx page:

<pw:portalmessage id="myPortalMessage" runat="server"/>

In this case we're using the ID of myPortalMessage, and we will use it to set the properties of the control in our code-behind file. Speaking of properties, there are the usual web control properties available, but the one's we'll focus on are Text, Type, and Visible.

In your code-behind (your .aspx.cs file), you'll need a handle on the control you've just created, and it's a good chance that only these two pages need access to it, so we'll declare it as protected within the class block:

protected PortalMessage DocumentMsg;

Text is the verbiage you want to show to the user. In our example above, the Text property was set like so in the code-behind file (aspx.cs):

myPortalMessage.Text = "Another document with this same file name has already been uploaded for this product. Please try another file or change an existing document for this product.";

Type is used primarily to set the icon displayed to the user. You have four types that are part of the PortalMessageType class:

• Error - used when something unexpected happened, often times this type is used when catching errors. The icon is a red square with an X in it. Your text will also be colored red.


• Information - this message type is handy when you need to show some help such as how to format a phone number or birth date. The icon is a blue circle with a lower case "i" in the middle.


• Success - typically we'll use this icon a lot when it's time for our performance review, "Look at all the success messages sir!" Actually this message is used a lot when a form was filled out and submitted successfully. The icon is a green circle with a check mark in the middle.


• Warning - we see this message type when there's been some sort of error we've anticipated. As shown above in the example, the user has tried to upload a file that already exists, so we display a warning. If the upload had failed due to network issues we would have displayed an error because that behavior is unexpected. The icon for this message is the yellow triangle with an exclamation mark.

To set this property, you could do something like this:

myPortalMessage.Type = PortalMessageType.Warning;

Lastly there's the Visibility property. Lots of times I'll show a message to the user, then I want that message to go away when they leave the page, click cancel, or try to start over. I don't want to clear the text and type every time, leaving some trailing HTML elements, so instead I simply set the Visibility to do the job:

myPortalMessage.Visibility = true;

At this point you should have a clean message on your page looking like the example above. I would say that it's time to celebrate your PortalMessageType.Success, but we've been PortalMessageType.Warning you about too much of that at work :)

The Best Part

As a software developer I had grown accustomed to being stuck in a cloth and metal box and only getting exposure to my fellow cube dwellers and my immediate supervisor. What drew me to my new post here at Passageways was the emphasis the company continues to put on all employees having direct contact with the customers. If I'm writing code, and I want to know how people will use a feature, I can go directly to those people and ask them right out, instead of getting a speculative interpretation.

Keeping with that mentality, I'm very excited about the inception of this blog and what it means for our customer-provider relationship. For me personally I look forward to sharing the ins an outs of our development process so that you can see how and where your participation steers our decisions. I'm also hoping that there will be time to show you how to better leverage the effort we put into our product from a coding point of view.

One last thing; we're currently in the design phase of our sprint (think of it as a sub-division of a project that lasts about a month). In the design phase, the features have been selected, but we are in the process of figuring out how we, as developers, will implement those features. Everything from what classes to make, to what colors and icons to use is part of this phase. This particular sprint is for our eForms Builder Module and has several bug fixes and one enhancement which is to make a copy of an existing form. If you have any strong opinions about how this feature should behave, now is the time to drop us a line!

Welcome!

We @ Passageways have been talking about starting a blog for quite a while and now, at last, it is here. We hope that this will be a great place for you to learn what's new at Passageways.

Thus far, our interaction with each other has been somewhat limited. We hope that this blog will give us the opportunity interacte more and to share ideas with each other. Since this blog is for both of us, please feel free to post comments and suggestions.