Converting a project to Unity - Overview

Alternate Title: What a Tangled Web We Weave

I ran the/my first post in this series by a friend that's a college level English teacher. She said I switched between a first person voice and second. I didn't really know what she was talking about until I typed the first sentence of this entry. I switched between, "As the prior post..." and "As my prior post...". I'm pretty sure that's what she was talking about. I should go back and fix that for those that are pained by reading such. Problem is, I don't know which voice I what or should be using. I'll try to stick to first person with this post and see how I like it.

As my earlier post indicates, I've got a lot to take in. Where do I start? Model View Controller (MVC) is a central to premise of what I want to be using but using that how I want to use it is predicated on understanding and using Dependency Injection (DI) with Unity. Mixed in with that is the other parts of the MS Enterprise Library. Those include the Logging block and the

I couldn't find an appropriate image
quickly enough so I went with the default.
Enjoy the puppy.

I'm pretty much stuck with a chicken or an egg. I'll go with the egg this time. (BTW: If you accept evolution and the science it's based on then the egg came first. Think about it.)

My baby step goal here is to replace the Object Factory and DI container in an existing functional test utility library I've been using. We'll call that the Test Framework as that's what the namespace is now. I figure it's a small enough bite I won't totally choke on it.

Some Background

The library was originally created by a developer that is no longer here so that's a resource I don't have available. My primary resource so far for learning how to implement Unity has been the Microsoft Enterprise Library 5.0 - Hands On Lab. Specifically, the Unity section. I've seen others and I hope to provide links to them in the future. I've found a couple that do a good job of explaining DI and why it's useful.

Just what does this Test Framework do?

The Test Framework is a fairly strait forward library for instantiating the Selenium test object and then  tearing it down when the test run is done in the Microsoft Developer Studio test environment. It's well under 300 lines of code in three classes. It's written in C#, as will all the examples I'll be showing. This same library might work with NUnit without modification. I hope to get around to trying that in the not to distant future.

The Test Framework library is included in the test project and then the TestClass inherits from the abstract class WebTestBase. Config files in the test project instruct the DI container how to instantiate the WebTestBase objects which are then used by the test to interact with the web browser of choice.

What this utility does is allow you to externalize the configuration so it can be deployed in different test environments with minimal effort. After setup of the initial configuration I can change which environment I'm testing against with a single change in the main app.config file. I can also add new targets without modifying the code. I just add a new config file for that environment.

Steps

• What I'm going to have to do is create a test project to test and develop the modified Test Framework against.** For a test project, I'll need a website to test against. As of this writing I don't have that decided yet. Maybe it will be very public site like Google.
• Next thing to do is make a copy of the Test Framework project and anonymizing the existing code base. Besides keeping y'all from knowing where I work, it will allow me to distribute it to those that might be interested in incorporating it in their test efforts.
• Bring in the Unity library and other parts of the EntLib as necessary.
• Get a basic implementation using the main app.config.
  The library should work, at least minimally, at this point.
• Do some research on how to structure the configuration files.
  In Lab 3 of the Hands On Labs (link above) for the Unity Block it shows how to use the main app.config file for setting up the container. However, the way we're using our existing DI framework, the main app.config points to a NamingContext.config file that then seems to point at the folder(s) and files where other configuration information is located. I'll get into why I want to keep this shortly.
• Port over some real tests and make sure it's working.

Other things to eventually look at

• Flesh out the library so that it works for all the currently available Selenium browser drivers. Not just the ones I use. (Firefox and IE)
• Using DI to inject the Selenium browser drivers. There may not be a reason to have them hard coded in the first place.

Somewhere in there I'm likely going to have to explain, or at least point to an explanation of, how the MS Test Framework works.

**The Test Framework is not intended to be a standalone utility. It has to be used by a unit test or other automation framework tool. You can actually use Selenium directly in your test project without this utility. This framework is actually built upon another one that I found and hope to link to that wasn't configurable.

Well, that's enough for now. Catch you soon.