Publicaciones hechas por por Urs Hunkler

Moodle in English -> Testing and QA -> Behat tests in PhantomJS slower

por Urs Hunkler -
Imagen de Core developers

I am astonished when I see that the Behat test I am working on runs slower in PhantomJS than in Selenium/Chrome on an iMac with Mavericks. I expected the test to execute faster with PhantomJS (v 1.9.7)

Is this the normal behavior with Moodle Behat tests? Or are there issues with my test?

Or may there be an issue with the PhantomJS installation? I get an PhantomJS error but the Behat test completes without errors.

The PhantomJS error message is:

[ERROR - 2014-03-23T11:42:47.896Z] RouterReqHand - _handle.error - {"message":"{\"headers\":{\"Accept\":\"application/json;charset=UTF-8\",\"Content-Length\":\"0\",\"Content-Type\":\"application/json;charset=UTF-8\",\"Expect\":\"100-continue\",\"Host\":\"localhost:4444\"},\"httpVersion\":\"1.1\",\"method\":\"POST\",\"post\":\"\",\"url\":\"/accept_alert\",\"urlParsed\":{\"anchor\":\"\",\"query\":\"\",\"file\":\"accept_alert\",\"directory\":\"/\",\"path\":\"/accept_alert\",\"relative\":\"/accept_alert\",\"port\":\"\",\"host\":\"\",\"password\":\"\",\"user\":\"\",\"userInfo\":\"\",\"authority\":\"\",\"protocol\":\"\",\"source\":\"/accept_alert\",\"queryKey\":{},\"chunks\":[\"accept_alert\"]},\"urlOriginal\":\"/session/3d9c7a70-b280-11e3-9542-67c64752bf31/accept_alert\"}","name":"Invalid Command Method","line":199,"sourceId":136951480,"sourceURL":":/ghostdriver/request_handlers/session_request_handler.js","stack":"Invalid Command Method: {\"headers\":{\"Accept\":\"application/json;charset=UTF-8\",\"Content-Length\":\"0\",\"Content-Type\":\"application/json;charset=UTF-8\",\"Expect\":\"100-continue\",\"Host\":\"localhost:4444\"},\"httpVersion\":\"1.1\",\"method\":\"POST\",\"post\":\"\",\"url\":\"/accept_alert\",\"urlParsed\":{\"anchor\":\"\",\"query\":\"\",\"file\":\"accept_alert\",\"directory\":\"/\",\"path\":\"/accept_alert\",\"relative\":\"/accept_alert\",\"port\":\"\",\"host\":\"\",\"password\":\"\",\"user\":\"\",\"userInfo\":\"\",\"authority\":\"\",\"protocol\":\"\",\"source\":\"/accept_alert\",\"queryKey\":{},\"chunks\":[\"accept_alert\"]},\"urlOriginal\":\"/session/3d9c7a70-b280-11e3-9542-67c64752bf31/accept_alert\"}\n at :/ghostdriver/request_handlers/session_request_handler.js:199\n at :/ghostdriver/request_handlers/request_handler.js:61\n at :/ghostdriver/request_handlers/router_request_handler.js:78","stackArray":[{"sourceURL":":/ghostdriver/request_handlers/session_request_handler.js","line":199},{"sourceURL":":/ghostdriver/request_handlers/request_handler.js","line":61},{"sourceURL":":/ghostdriver/request_handlers/router_request_handler.js","line":78}]}
Promedio de valuaciones (ratings): -
Imagen de Core developers

Hi Tim,

thank you very much for your answer.

1. I have created the Behat steps driving the Moodle UI knowing that this will be slow - and it is really awful slow.

So I need to investigate into 2.) 

Imagen de Core developers

I need the data of a custom user profile field in a Behat test. 

Do I need to create and enter the data with Behat steps or is there a predefined way - like a generator?

I have been searching Moodle forums, the Moodle docs, the net and the Moodle code base but could not find any information or a hint how to create and add data to a custom user profile field.

Promedio de valuaciones (ratings): -
Imagen de Core developers

The discussion related to the broken block drag and drop has come to an interesting point: There are some fundamental changes in Moodle necessary to solve the issue.

Mary's and my proposal to use a layout file for the /my page as part of a flexible solution is not seen as an option for Moodle. It would be interesting how other theme designers / Moodle developers interested in themes think about this aspect. I post the answer I have written in the tracker here again because I think a discussion about the layout file approach in Moodle makes sense in this context.

...

In one aspect I disagree - the /my page must be implemented with a layout file. This is my opinion based on the work I do and the experience I get from my work: PHP development, JavaScript development and theme design.

The /my page is a special page type in Moodle. With Moodle 2.x all page types are listed in the Moodle theme config:

base, standard, course, coursecategory, incourse, frontpage, admin, mydashboard, mypublic, login, popup, frametop, embedded, maintenance, print, redirect, report, secure

Each of this page types has its individual characteristics and is a candidate to get its own layout file. The reason to decide when to use a layout for a page in a theme should not be how many pages use this layout but should be if the layout helps developers and theme designers to display the content on the page in the appropriate way.

A coding tendency in Moodle is - as I see it - to handle most tasks programmatically in PHP - use renderers, methods etc. wherever possible and avoid the use of direct written HTML wherever possible. And now more and more code is written in JavaScript in addition to PHP. And a coding rule is to avoid code duplication wherever possible.

Layout files are HTML files with included PHP calls (direct written HTML). And several layout files contain the same basic page structure (code duplication). So the tendency is to use as few layout files as possible and solve individual demands for some pages with specially written PHP and JavaScript.

With the /my page we have a good example that the PHP/JavaScript coding approach leads to trouble if you change code in one place and don't change related/connected code in other places => drag and drop breaks. And we see how difficult it is to track the connected places where code needs to be changed. If for the /my page a layout file would have been used some themes could use the old method to include blocks and other themes could use the new method and nothing would break (I guess without having checked the details).

So please rethink the strict rules to always avoid direct written HTML and to always avoid code duplication and use layout files instead for all pages where otherwise special new methods in PHP and JavaScript would be necessary.

One advantage of using layout files is that theme designers can more easily adopt the page layout to design/client demands. With code written in PHP and JavaScript these changes are not possible if the code has not been implemented as a renderer.

So I am sure Moodle would work better using/offering more layout files for the different page types than adding complex code to core to handle differences - better for theme designers and better for developers too.

What do you think?

Imagen de Core developers

I have created a patch to solve the block drag and drop issue on the /my page in Moodle 2.6.1. If you may be interested you may get the patch until Moodle HQ solves the issue in core.

And you may vote for MDL-41551 in the tracker to (possibly) speed up the work.

Promedio de valuaciones (ratings):Useful (2)