Hello Garry, thanks for taking the time and pointing some things out - it was really helpful: yesterday I managed to run tests on my own testswarm.
On 16 Okt., 19:22, Garry <[email protected]> wrote: > Hi, I hope the following answers help: > On Oct 12, 6:36 pm, Oliver <[email protected]> wrote: > > first of all: "testCase" and "testSuite" - I am still a bit confused. > > I am afraid the addjobs gui isn't clear about it as you are supposed > > to add suites that form a suite. > > A job url is pointing to just any test page that forms a suite, you > could optionally put a big suite there or break into series, all > depend on you. That means: There are virtually no restrictions on how to layout the test-suites. Great options here, I like it. > > > next question is about the use of JQuery: > > - when testing a mootools based app, am I supposed to use the > > mootools dollar safe mode? > > [...] > > Swarm is test tool and application ignorance, in this case it knows > neither which library you're using to build the application nor the > underlay testing framework, the jQuery library you see there is only > used in the swarm runner, while the actual testing are running inside > a separated frame, be sure that nothing conflict there. Allright, that was exactly what my question was about. A very helpful answer to me. > > Another question about gui testing: When using TestSwarm with one of > > the supported test frameworks, are there any restrictions for the > > testing of the GUI? Is it possible with mootools/jsunit AND with > > mootools/jsspec ? > > In case you're testing the GUI via unit test way ( on contrary to > manual GUI testing ), things are mostly the same, except the only risk > that the iframe environment may contribute to a wrong result ;) I still didn't manage to run jsunit tests, but at least JSSpec is working fine. And JSSpec is a very nice testing framework. The situation with the iframe seems to be optimal for me. My GUI- related tests do run flawlessly in that iframe and they do produce exactly the expected results. > > and, please, a few questions concerning inject.js > > - where to add inject.js to my test page > > - after or before the loading of my test framework? > > - as the last javascript in the page? > > The inject.js file is the key for a successful live in the Swarm, > while the standard way is to create your own version of this build > script > http://github.com/jeresig/testswarm/blob/master/scripts/testswarm-jqu... > But I can tell the simplest way ( and if you feel perl sucks ) is just > to link the inject.js file directly in your test suite html: > 1. when your suite is running in Swarm, the injection communicate with > the runner; > 2. When your suite is running standalone out of Swarm, the injection > will check there's no Swarm env thus leave everything untouched. Yes, I can confirm that the inject.js does not harm my tests when running outside the swarm In my (now working) setup, I did include inject.js as the very last javascript in the test-page, after jsspec and after my to-test code. My testing code starts via the onLoad() trigger. As already mentioned, things do work for me this way now. > Be ware about time out, TestSwarm is designed to be hang-up proofing, > so on the negative side you may experience test time rushing issue > ( Swarm is dropping the client while test is still running ), this > require you to tune the configurations in many places, e.g. heartbeat > life-cycle etc. Allright, I'll have a look at the heartbeat thing again. Thanks Garry, I am very happy now. TestSwarm is awesome - just what I need. Best wishes, and thank you once again Oliver --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TestSwarm" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/testswarm?hl=en -~----------~----~----~----~------~----~------~--~---
