One day left after Christmas 2008 - time to write a mission statement.
Molybdenum started with its first public release on AMO two years ago. As the founder of the project I'll try to write some words about what brings Molybdenum forward and what goals we want to achieve. Currently we are three active developers and, hopefully, what I'm thinking and writing about The Molybdenum Project fits their general view. In detail, it does not. And this is a great thing. It brings us forward - the power of Open Source.
Are you curious about the name "Molybdenum"?
It should be a little bit of a riddle. The successor of Molybdenum is Selenium. Ok, a chemical elements name choosen as an implication. But why is Selenium itself named that way? I don't know exactly... But if you know just another big thing in testing - Mercury and you googeling about what they could have to do with each other - you might find an answer.
Molybdenum has the order number 42 http://en.wikipedia.org/wiki/42_(number).
There is a part of the Selenium tool chain, which at first view does the same as Molybdenum: Selenium IDE. Why it's totally different should be clear after reading this mission paper.
Working as a consultant for software projects, I was confronted with the poor possibilities of web UI testing every day. I was a member of projects where UI tests were started enthusiastically - and died some weeks later because it was an unsolvable problem to maintain the tests together with the fast evolving application. Other challenges appeared in the second or third attempt...
All well known solutions and tools had a problem:
They were not really UI testing frameworks - they tested on the HTTP protocol layer, simply ignoring the behavior of the browser itself.
Or they were trying to emulate a browser - never the way testing DHTML was possible.
There were other tools which really tested on the UI level - but they cost money - much money and nerves of the students hired to do the job after the money was gone for license costs and highly expensive consulting.
The idea was to use an interface, which is operating system independent and more or less standard to attach a testing tool to: the DOM. Googeling for a framework to emulate DOM events, I found the selenium libraries - two years ago in an early stage.
Selenium was fulfilling several anti-patterns of testing:
- add complexity to the application under test - only for testing
- be invasive while testing - change the application or application infrastructure a way it is not done under production circumstances
- a test can be complex, it has to be understood by the writer of the test only
- a test can be fragile - simply add an extra process step to find out if the test result counts the right way
- tests haven't got to be automated - simply start them manually
I think, the Selenium project was aware about these things, and they solved most of the problems over the time.
But I felt, they were in most cases replacing one anti-pattern with another - not really solving the problem. So I tried a different way. First I removed complexity at all by removing (or ignoring) one goal of the Selenium project: cross browser testing.
It is more important to have reliable and simple testing capabilities than cross browser testing possibilities.
Molybdenum is realized as an Firefox (Mozilla) addon. This was limiting the testing to the Mozilla browser and derived browsers with XUL capabilities. But at the same time, all extra complexity of proxying, deploying tests with the app under test itself or later on, injection with all the caveats with https certificates or apps killing frames were simply gone.
Additionally, Molybdenum provided a simple way to start tests automatically and getting back a report.
These are the goals of Molybdenum:
- Make web UI testing non invasive where possible
- Testing, especially UI testing is communication - tests and test reports have to be understandable by non technicians as well
- test maintenance capabilities are extremely important
- test automation is the basis for continuous integration and effective testing in general
We can derive concrete tasks from the goals now:
- provide a test infrastructure, where the impact on the application under test is as small as possible
- make the test infrastructure as simple as possible, so everybody can fire tests and possibly write tests
- provide reporting facilities
- make test creation and maintenance independent of any programming language and as simple as possible so non technicians can understand tests as well
- remove all tool chain breakage in the process of test creation and maintenance - no language transformation
- provide excellent integration in build automation environments
Claas Thiele (December 2008)
