I’m going to be writing a series of posts on the automated Functional Testing system we have setup against our SAP Portal. I’m not sure how many posts it’s going to take, we’ll find out as we go. Here is the first an introduction. OUR TEST PROCESSEvery time we fix a bug or add a new feature we write a test or series of tests which prove the fix/feature is working. Now we’re not being forced to do this testing by some big bad manager so why do we do it? Are we mad? Do we like writing lots of extra code which doesn’t add new features or fix bugs? NO. This testing believe it or not has lots of benefits for us as developers: • Confidence – As the number of tests build up over time we know the new fix/feature has not just broke something we fixed last week. • Time – No more having to open up the browser and click through a series of boring time consuming steps to prove the latest fix is working. The automated testing does the donkey work for us. • Fun – Ok we are a little mad! But there is some (maybe perverse) pleasure in watching lots of tests run and getting no failures. Knowing if we had to test manually it would take all day and we’d likely miss or skip something which would later come back to bite us. HOW DID WE END UP HERE?We are a small team which took over development/maintenance of an external SAP portal application. The original developers were contractors who had long gone. It was a scary prospect fixing code and not knowing if the “fix” had managed to break some other part of the application. It meant after making even the smallest change lots of manual testing was needed. Now it goes without saying this was not fun, not fun at all. There had to be a better solution… A BETTER SOLUTIONWe started looking around the web and read lots of good things about a free (yes free) tool called Watir (pronounced water). It allows you to automate Internet Explorer using the scripting language Ruby. I thought it would be pretty cool if we could use this tool to test our SAP Portal Application. After lots of trail and error I managed to connect to the portal, login and run a test! Now after six months of bug fixes and new features we run hundreds of tests before each release of the application. COMING UP IN PART TWOIn the next post I’ll explain how we setup the environment, no more talk just lots of practical downloading and installation. NOTE: Anyone with test driven development knowledge will rightly say we should be doing this sort of thing at a unit test level first. I agree and fully intend to do this but as yet I’ve not managed to get the Unit Test framework of the SAP Portal working.
