CS 242 Fall 2010 : XML Processing

This page last changed on Aug 09, 2010 by cemeyer2.

Using XML as a Backing Data Store for Functional Testing

Week 1 – Writing the data parser/extractor

Imagine you are a software engineer for a large computer corporation, who happens to be in the business of selling large servers running Unix and Linux to other corporations around the world. One of the selling features of these servers is that they have an easy to use web-based interface for configuration management of the actual hardware. While this is all fantastic, nothing is ever actually good to go unless it is well tested. You happen to be on the team of software engineers that has been tasked with developing a new test suite for this web interface.

Whoa, testing a web site! I’ve heard of unit tests before, but how does something like a unit test apply to testing the functionality of a web site? Isn’t a website about things like aesthetics and design as well as functionality? How do we test it all? Luckily for you, we are going to gloss over those details, but if you are really interested, you should have a chat with Charlie (this whole narrative might be based on something real). Your team leader has decided that each of the tests in the test suite your team is tasked with writing will need some sort of configuration information, such as what host is the web site under test running on, what type of server is it (the web site can do different things on different models of server), what port to connect on, etc…Your team has determined that XML is an excellent way to store all this configuration data.

Your job, well you really don’t have a choice to accept it or not (but you are getting paid fictitious money for it in our fictitious story), is to write the XML parser that will extract out the configuration data for each test in the suite. The overall suite will have one XML file that backs it, and each test will have its own section. A sample XML file might look something like:

You will notice in the above snippet, there are two main components to the XML file:

  1. the global section
  2. a target section for each test

Here’s how your parser/extractor should work: Given the path to the XML file, the test name, and the name of the configuration element to extract, find the proper data in the file and return it. It should do this by first looking for the element in the proper test target’s section. If it is not found there, it should look in the global section. If it is not found there, well thats for you to decide how it should behave.

Your API will need at least three functions:

  • a function to get a configuration element and either return null, throw an error, etc if it is not found
  • a function to get a configuration element that also takes a default value and returns the default value if it is not found
  • a function to see if a configuration element can be found in the file

This assignment must be done in Java, but you are free to use any XML library you wish to aid you in your efforts (don’t worry about license problems with our fictitious corporation).

Things to watch out for:

  • what do you return when you encounter an empty configuration element: <element/> or <element></element>
  • how will you handle malformed XML?
  • what are your error conditions and how will you handle them?
  • did you create a DTD to ensure that the XML is valid? Are you verifying using it?
  • can you handle comments in the XML?

Make sure you test your code for all of these things!

Week 2 – Handling Passwords

Since the servers that you are testing require you to login to them using your personal login information, it makes no sense to leave your personal passwords sitting in the open in an XML file, does it? Especially since these XML files are passed around from user to user, your team leader has decided that your configuration parser/extractor should be able to encrypt and decrypt configuration elements in the configuration file.

Obviously, this should be an automated process….so if your parser encounters a line in the file like:

it should transparently transform it into:

All elements without an “encrypted” attribute can be safely ignored. When reading back the file, it should be transparently decrypted and fed into the tests. Obviously, we are glancing over the nuances of security here, but for arguments sake, go with it.

Things to watch out for:

  • when modifying the XML file, be sure not to loose information or cause collateral damage
  • what encryption algorithm will you use? (DES or weaker is not a good choice, think AES)

Again, build on last week’s assignment and use Java again. Feel free to use any libraries that suit you.

Week 3 – Writing a Configuration File GUI Editor

ill develop this if the assignment seems worthwhile

Document generated by Confluence on Feb 22, 2012 18:13

  1. No comments yet.

  1. No trackbacks yet.