Discussions

News: Using MCP for Automated Testing of Ajax Applications

  1. Ed Burns put together the MCP - the Mozilla Control Program, named partially in honor of the evil OS in Tron - to enable testing AJAX-enabled applications using JUnit. The MCP allows full page inspections, as well as examination of AJAX responses, using an actual browser to do the testing. This article discusses the use of MCP along with some screencasts to show the client in action.

    Threaded Messages (8)

  2. Any feedback?[ Go to top ]

    Hello, I'm anxious to hear if anyone has tried this yet. I showed Hani the API and he had a few suggestions, which I will address for the next alpha release. However, he suggested dumping the name "mcp", but I'm not sure I want to let go of that just yet. Ed
  3. Hi Ed: Thanks for the tutorial and screen cast on MCP. Considering I keep a copy of Tron on my ReplayTV (a Tivo like device) for viewing at a moment's notice, I'd say... Keep the MCP name! I really like the idea of AJAX functional testing utilities. You may know of my PushToTest SOA governance and test automation tool (details at http://www.pushtotest.com). I've been wanting to add AJAX functional testing for a while. PushToTest 5 wraps functional tests into scalability tests with no extra effort. I was hoping I could use something like MCP to author AJAX tests and then plug them into TestMaker for a load test. Especially to see how well a host serves AJAX's XML content under load. The problem I see is that MCP requires the browser environment for playback. That limits the design to functional testing. What I'd like to see is an easy way to turn my AJAX functional tests into scalability and performance tests. By the way, Selinium seems to have the same problem: http://www.theserverside.com/news/thread.tss?thread_id=44750 The only solution I've seen is SpikeSource's TestGen4Web in that you can replay tests without the browser. The downside, of course, is it doesn't give you all the great AJAX testing of MCP. Any ideas? -Frank Cohen http://www.pushtotest.com
  4. Hi Frank,
    The problem I see is that MCP requires the browser environment for playback. That limits the design to functional testing. What I'd like to see is an easy way to turn my AJAX functional tests into scalability and performance tests.

    By the way, Selinium seems to have the same problem:
    http://www.theserverside.com/news/thread.tss?thread_id=44750

    The only solution I've seen is SpikeSource's TestGen4Web in that you can replay tests without the browser. The downside, of course, is it doesn't give you all the great AJAX testing of MCP.

    Any ideas?

    -Frank Cohen
    http://www.pushtotest.com
    Badboy (http://www.badboy.com.au) can run fully AJAX enabled tests "without the browser" in it's newest version (2.0 - still in beta). Of course, actually it's not really running "without the browser" - what it really does is creates multiple windowless instances of the browser as background processes and controls them all to run the test scripts - which you can then scale up until either your test machine or your server falls over. So I don't know if that meets your criteria, but it would probably be adaptable for the kind of job you are looking at. Cheers, Simon Sadedin. Badboy Software.
  5. Badboy license and instances[ Go to top ]

    I checked out Badboy and it looks good. Two questions: 1) PushToTest 5 will be under a dual license: the source is GPL and the compiled run-time is under a free-to-distribute license. To ship with PushToTest 5's run-time we would have to distribute it as a free plug-in and I believe Badboy is a commercial product. 2) How much memory is needed to create an instance of a running functional test? On a 2 Gbyte 3 Ghz Linux box we would expect to have 500-1000 concurrently running functional tests. Can Badboy have that many browser windows open? -Frank Cohen http://www.pushtotest.com
  6. Re: Badboy license and instances[ Go to top ]

    I checked out Badboy and it looks good. Two questions:

    1) PushToTest 5 will be under a dual license: the source is GPL and the compiled run-time is under a free-to-distribute license. To ship with PushToTest 5's run-time we would have to distribute it as a free plug-in and I believe Badboy is a commercial product.
    Yep. Badboy is a commercial product, but with very flexible licensing, and its definitely possible to make an arrangement to facilitate distribution or other kind of integration if it makes sense.
    2) How much memory is needed to create an instance of a running functional test? On a 2 Gbyte 3 Ghz Linux box we would expect to have 500-1000 concurrently running functional tests. Can Badboy have that many browser windows open?
    This is a good question, and to be honest the scalability hasn't been tested yet to the levels you are talking about. I've regularly run tests that go to 100 browser instances and this is accomplished quite easily on a 1Gbyte box, so I suspect it will be at least in the ballpark. Obviously the amount of memory consumed depends a lot on the page that is loaded by the browser instance to host the tests - the minimum seems to be around 2MB for a nearly blank page. (See contact info on the web site if you'd like to discuss more.) Cheers, Simon.
  7. Who embeds who (or is it whom?)[ Go to top ]

    Sounds good and I'll contact you directly. Current plans for PushToTest version 5 (coming in May) is to bundle SpikeSource's TestGen4Web, however, the design allows BadBoy to plug-into PushToTest 5 too. PushToTest 5 is a distributed test environment for scalability and performance tests and service monitoring tests for governance. The environment runs tests that are created using JUnit, TestNG, in Java, Jython, or any other application or language. The test runs, asserts a valid condition of the result from the service under test, and PushToTest 5 takes care of running the tests on a distributed set of TestNodes, monitoring resource usage, and summarizing the results in a set of charts. PushToTest 5 is GPL, so you guys could ship PushToTest 5 with BadBoy. Here's where you can find details on PushToTest 5: http://downloads.pushtotest.com/PushToTest_WhitePaper.pdf http://downloads.pushtotest.com/tm5/TM5_Specification.pdf http://downloads.pushtotest.com/tm5/TM5_UI_Design.pdf -Frank Cohen http://www.pushtotest.com
  8. HtmlUnit merits a try[ Go to top ]

    For load testing I use HtmlUnit. I have a wicket application that uses Ajax. With my app deployed with wicket version 1.2.2 I can receive modified page with components inserted through ajax. However with wicket 1.2.3 and 1.2.4 in which the js ajax engine has been rewritten i get a runtime exception. I see that wicket1.2.5 has been released and another version of htmlunit as well. Haven't yet tried if the js runtime error is solved in those but i will need to by 10th of april when i have to present the proof that our app can hold as many clients as agreed-by doing a load test-. My only option is HtmlUnit deployed with wicket1.2.2 currently.
  9. Sahi anyone?[ Go to top ]

    Has anybody seen Sahi - http://sahi.co.in/ ? It works on IE and FF (because its all javascript - so theoretically it should work with most), records scripts automatically (look ma, no coding to test!), and yet allows scripts to be edited. Scripts support javascript-like programming constructs. It generates junit-like reports, has test suites and works with ant too! IMO this is the kind of tool required for UI testing - not one that requires more coding. Caveats : It does require opening up a browser instance, and some workarounds to actually kill the instance. Also it can't yet capture things like window closes, and its dnd support needs some turning on ;(. But otherwise, its a pretty good tool; and the biggest win has been the zero install for the business folks. Other features that are good: centralized store for scripts, and the ability to point to a script URL and have sahi execute it. I am not the author of Sahi - just happened to use it and think its a great idea - especially when compared to all the effort of writing code to automate UI testing.