Tuesday, July 31, 2012

Background of the Test Framework WebTest

Thought I'd give a little credit where due and explain a bit of the life-cycle that the Test Framework has gone through.

The Good Ol' Days

Like a great deal of decent code, it's stolen copied from someone on the web. This holds true with the Test Framework I've been using.

I think the original code for the Test Framework came from this article Selenium browser UnitTesting from TeamCity from the blog Software Creations – Orn Kristjansson. I'm not positive but it looks good. I'm thankful for the original posters work.

When we got the library in house I used it for a little while as it was originally presented before one of the developers, Jared, got his hands on it. He tweaked it to make it more configurable with an in-house Dependency Injection Object Factory thingy**. He also got it to automatically start the the Java engine that Selenium needed at the time instead of using the .BAT file I had been using.

That post mentioned above was from July of 2010. Back then, Selenium worked much differently than it does when I'm posting this. Things changed a lot with the release of 2.0, the WebDriver version. I'm happy with the changes that were made if you don't mind me saying so.

After Selenium 2.0 came out, I went into the Test Framework library and butchered modified it to work with the WebDriver version of Selenium. Part of which was taking out the starting of the Java engine (Which had broken by then) and that external dependency. I also messed up how things worked.

With that experience with the library my confidence in coding grew and I made some modifications to make pointing at different environments that needed to be tested easier to do. Now, only a minor change in one place can change that environment under test as well as the behavior of the test suite. That's to include using different test data against the site under test. Those changes worked but it was a convoluted implementation. Only when I went in to start this rework did I actually see what I had done and then correct it.

What's Changing

As I think I've mentioned before, we're planning on upgrading our in house version of an enterprise library. It includes much of an early release of the MS Enterprise Library plus some internally developed utilities along with an external Dependency Injection/Object Factory thingy**. I've made the command decision to switch over to a newer version of the MS Enterprise Library without the 'porting' to our namespace. That also includes replacing that in-house Dependency Injection Object Factory thingy with Unity.

** "Thingy" That's a very highly respected technical term. You should learn it and use it often.

No comments:

Post a Comment