Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tests framework to HTML-based apps #65
I am working on a proposal to test HTML-based apps. This solution is an initial experimentation, based in Jetpack SDK tests framework, and may also serve to do other things in "batch mode". The general design is:
A (for HTML apps) test solution should run Chromeless a number of times, one time or many, for each test/sample application. Chromeless itself is a Jetpack-based application so its main component is located in :
Following the test framework in Jetpack SDK, we can place a test directory in:
And then, when using "test" execution mode ( against Python Cuddlefish cfx ,) the test-main.js should be executed. And if in  there is a exports.main, then it means that test-main.js can access the scope of main application. So, in theory, test functions in test-main.js should be able to execute functions over main.js, for example it should be able to launch a Chromeless-based HTML app -- default main function.
In a normal case, for a Jetpack app, the test rules ( assertions and function calls against main app ) are placed in test-main.js and are specific for each Jetpack app. In our design, however, the test-main.js would act like a proxy and perform actual tests that should be located in the actual Chromeless sample app directory. So, for example, a Chromeless app that is located in ./samples/myApp would need a file for tests -- let's say a tests.js file. This file would have a list of test functions and these functions should be able to execute calls in the scope of the main HTML app, and as well perform assertions over back to the test-main.js which in turn will do the assertions as it does with Jetpack SDK.
To get started I took Jetpack recent SDK and merged with some fundamental Chromeless patches to have it launching XULRUnner-based app and the HTML-based app. The following is work-in-progress:
This sounds reasonable, but I'm having some trouble getting my head around things. Here's some questions:
Thanks for the questions.
But under the main Python's cuddlefish code, what happens is that we are calling a "cfx test" = run command ="test. So here is a snapshot of a hardcoded test script for one specific app:
It instructs Python's cuddlefish code to run in "test" mode which will trigger the execution of another app instead what we would normally expect, our actual --pkgdir app ( our top level Jetpack SDK-based app ). The main app executed, in this mode, is
And this will execute a testing app under our package dir ( --pkgdir ), under ./tests directory. Above referred, run-tests.js, will find all the ./tests/test-* files for a given --pkgdir app.
And here is an initial test file:
Notice, looking in the above file, that testBrowser() function does call our exports.main for the ./packages/chromeless/lib/main.js. It is passing a hardcoded ( TBD fix ) filename for the actual HTML app.
3)4)5) you mean privileged mode = Jetpack app and app mode = Chromeless target app right?
This solution is going towards Chromeless target apps -- means to grab/execute tests functions described in the scope of the actual target app ( HTML/JS app ). The actual Jetpack-based app, which I think you refer as privileged mode, should be done with no changes in the Jetpack SDK I think. For pure Jetpack one you can check examples on tests if you look in ./examples/reddit-panel/tests/ for instance ( jetpack SDK ).
The hardcoded case is there -- it's not yet taking the test functions from the context of the Chromeless target app ( TBD fix ). If you look in the above test-main.js, you will see that it instructs Chromeless main to start itself, it passes a browser/app filename, it waits 5 secs, then it grabs the title of the main app. It's meant to prove that it does intercept the DOM at the app level.
An actual JS for tests, for a given Chromeless target app, could be:
So when said test-main.js is executed, it would execute if any ( pre-bound ) test functions. And these would perform the actual call to assert functions in the context of the test-main.js. I am moving towards now to this last part so the code that is hard coded in test-main.js, that currently access the DOM for an actual target app, will not exist in here.
An up to date proposal patch is here:
We have now, landed, our initial tests framework. The idea is basically a reuse of Jetpack SDK test-harness, except that we are not using the run_app approach for Mac OS X. Instead, for Mac OS X only, we are using appify approach which creates a local standalone app and simply does open the app that was created in the hard disk.
So, now, we will need figure out how to pass a new profile for every iteration. I think this is important because we don't want to run tests with always the same default profile that was created by a given XULrunner app. By the way, when running XULRunner app with the .app / Mac OS X open, XULRunner makes its decision to create the profile or reusing existing. And it creates in a place like this:
/Users/user_name/Library/Application Support/My Chromeless App/Profiles/6y09zele.default/
On the other hand, when calling XULRunner using command line, the normal approach to use profiles is via arguments:
xulrunner-bin -profile path_to_profile
There are ways to tackle this: