Serious JS Testing Base [#1339864]

So after a couple of days' work, i'm closer than ever from having JS testing working. Actually it's already working, it's just not pretty enough to be posted yet.

It's a huge task – with all the behaviors we're looking at way more than a hundred tests – and I think i'll open a couple of issues when the time comes for a few tricky behaviors. But for now i'd like to talk about the direction i'm going.

The plan is to take OL.js tests and change the initialization part to fit how we do things in the module, it's the whole point really. OL.js already works, we just need to make sure we're not breaking it.

for every ol_behavior_xxx.js have a ol_behavior_xxx.test.js, for now it's in the same directory
create a test map with all behaviors enabled so that every settings are created on the JS side
take over attachbehavior to be able to activate a specific behavior how we want and when we want
port original OL.js tests to qunit (it's only a search/replace, awesome)
fix a looooot of code

1–3 are done, i've started 4 today map creation and dragpan are done, i'm working on geoloc then the 20 others.
The tests code are pretty straightforward, the code for initialization is quiet complicated though i'm still looking for ways to simplify it but i guess it is pretty complicated in itself, so no other way.

The soon to be posted monster patch will require #1332836: Behavior re-architecting, use map level event system, it's just not possible otherwise :þ and I've had to rewrite a couple of things in our main openlayers.js to make testing possible and clean up some more cruft. A side effect of tests is that every behavior will now have a detach function that clean up the controls it added (we need it to clean up the map before continuing to another behavior during the test) making this module really good citizen in JS land.

While adding tests i'll be cleaning up layer/features handling in JS too, I've been hitting a couple of problems with projections so i'm going to be spending an aweful lot of time with them. I hope i'll be able to improve the support for fancy projections thanks to that. Once most of the tests are working i'll be looking at using the QUnit module, but the module will need some backporting first to work with our tests.

Any though, wish welcome, better to know early if i need to support some strange use-case.

Comments

Comment #1

zzolo CreditAttribution: zzolo commented 13 November 2011 at 19:14

Hey @nod_. Thanks for your hard work. Most of this sounds good.

1) Can you provide a sample test, or at least the direction its going?
2) I am very weary of rewriting all the OL library tests (item #4). What is the benefit of this?
3) Monster patches and "fixing a loooot of code" are no good, at least in the scope of a single issue. At the very least, I hope you are working on a new branch that then can be put into a patch that contains multiple, distinct commits. Please try to focus on just getting a good testing infrastructure, some porting of existing code, and good documentation for others. Things like projections should not be handled in this sort of effort.
4) I really like the idea of using the QUnit module (though I haven't used it yet)
5) I do realize that the behaviors re-architecting will be necessary for this. What I am thinking is that I will aim to do a release next week without the testing and behaviors architecture changes, and then put these in there after that. I am just worried that there would be too many changes in one release (though if we had more tests, I could be more confident :).