There is no plan to create a npm package. All shared code should be in mediawiki/core.
Apologies for '../../../../../', it's caused by my lack of JavaScript experience. I am sure we can get rid of it (with some help from more experienced JavaScript developers) without creating a npm package.
Why not?
The code can still live in mediawiki/core inside package.json as a versioned dependency. It also means extensions can share that code easily.
This is what that would look like:
This is no different from how we did mediawiki-selenium releases in Ruby?.
Neater, no?
One of the major differences between Ruby and Node frameworks is the way we implemented sharing code. I see that we have never properly documented and/or explained it. Both approaches have advantages and disadvantages. I guess I need to document it properly. Tracked in T182692.
@Jdlrobson I support publishing these files from mediawiki/core as a package on npmjs.org. This allows much easier use by extensions and also avoids much complexity in future updates. In the current state it is impossible to make breaking changes to the page objects in mediawiki/core without either breaking extension tests, or having to update all tests in a Depends-On commit that needs to be merged at the same time. That's an anti-pattern we first ran into when we had only a single version of JSHint installed on Jenkins. We learned from that mistake and should not make it again.
Publishing it as a package means we can remove or change parts of the page object interface over time, without requiring a large-scale migration each time.
@ZFilipin (WMF) I agree we should continue to maintain these files in the mediawiki/core repository. I recommend adding a the package.json inside the directory where these files are maintained. Then, when it is time to make a release, you just run npm publish on a clean master branch.
I really did not think running tests is not so much more complicated that before. It's just two commands. We could create scripts in package.json to make it easier.
Please keep in mind that only one person is working on Selenium framework. Because of that we (my team, not royal "we") have decided to support only two environments. MediaWiki-Vagrant and Jenkins. The assumption is that if people prefer a custom environment they will be experienced enough to be able to make adjustments to Selenium framework to make it work for their environment.
In node development, the expectation I have is that I can run `npm run selenium` to run tests. Previously we used `bundle exec` which would be the Node equivalent.
Because that is not possible, I have to read documentation. I do this every time I need to troubleshoot tests as it's difficult to remember how to run them.
It's definitely something I can live with, but it is something I miss about the old stack. I feel like it should be possible to get `npm run selenium` I just haven't had an opportunity to investigate that yet.
Please keep in mind that Ruby and Node frameworks are similar, but not identical. Some things possible/available in one are not possible/available in the other.
Also, how to run tests is documented in readme files (core, Popups, RelatedArticles)...
That said, I agree that running tests should be as easy as possible. I have created T182691 so I don't forget about it.
I might be missing the problem here. You can create ArticlePage with needed functionality in the extension or mediawiki/core (if you need the same functionality in several extensions).
Sure, but nothing exists (yet) in mediawiki/core. This means we are starting with a blank slate. To be honest, I am a little frustrated that we have shifted from Ruby to Node without providing the infrastructure need to make that shift.
We need to switch from Ruby to Node because Ruby is no longer supported. What is implied by this is that we need to rebuild the entire Ruby support libraries that we have been using and that we are responsible for doing that.
This is a lot of work (and I'm personally finding it overwhelming and stressful). We are a small team with lots of key products and are struggling to find the time to fit this work in alongside all the other work we need to do. Progress is slow.
I understand the frustration. We are also a small team and I am the only one working on Selenium support. Please understand that I could not really know what features other teams would need. I did my best. The best way to resolve this would be to pair on implementing the required features. Another way would be to create tickets in Phabricator and assign them to me.
Screenshots for every Selenium and assertion failure are already implemented. Let me know if you need help.
T179188 is about video recording.
Great. Glad that bug exists. The single screenshot is not too helpful. For instance, it's not clear at all what's going wrong in this failure without seeing screenshots/video for each of the stages.
Write tests section of Selenium/Node.js page links to MediaWiki repositories that already have Selenium tests.
WebdriverIO repository has example code. Please notice pageobjectfolder.
I agree that FAQ would be a good page to have. Feel free to create it and I will do my best to populate it with answers.
Please keep in mind that many questions are already documented upstream. Also, upstream has vibrant community. Any time I had a question, I got an answer quickly.
Regarding multiple inheritance in JavaScript, I do not have any specific advice than generic Composition over inheritance. Since my JavaScipt-fu is white belt, I think somebody else should give advice here.
There is no plan to create a npm package similar to mediawiki_selenium. That said, instead of such package, all shared code now lives in mediawiki/core. That is a deliberate architectural decision. As far as I know that pattern is already used in PHP and JavaScript unit tests. @Hashar could correct me if I am wrong.
Discovery team has found another API package instead of nodemw. mwbot that has some features they need. You can follow T181284 for more information.
If nodemw/mwbot does not have features we need, we can always contribute upstream. If upstream proves to be unresponsive, we can always fork.
"It's not clear how to mix and match pages with different properties without utilising multiple inheritance. Please provide guidance."
I've been mulling this one over and my response would be as follows:
"Mobileness" is not a property of the page; it's a property of the browser. For better or worse, it's a property of the site too. Protectedness and watchedness are properties of the page. So, bearing in mind that Minerva might present different IDs for certain interface elements, there are 2 pages in your example, Page and MinervaPage. Both have isWatched and isProtected getters and watch/unwatch and protected/unprotect mutators.
"Creating page objects for every single page is very cumbersome."
I'm curious, didn't we do this with the old stack too? Is it that creating Page Objects in the new stack is cumbersome?
I think creating page objects in any stack in cumbersome. The ones in Ruby were done over time, but here we are having to build them all in one go.