At this point we assume core is using ES6, following Airbnb coding standards.

There are hundred of testing libraries. One of the most used testing tool is mocha (also used by airbnb). But it doesn't really matter, most testing libs are the same. This one has integration written for (almost?) everything we can think of using in core js.

The patch is big since it's a diff from my es6 branch. I split the test code in it's own patch for showing how it looks like. For now apply the huge patch and run the following

npm install
npm run test:core

This is the output (with code coverage):

$ npm run test:core

> Drupal@8.3.0 test:core …/drupal
> nyc mocha -r jsdom-global/register $(find core/ -name '*.test.js') || exit 0



  Drupal
    #checkPlain()
      ✓ should escape html strings safe for printing


  1 passing (6ms)

---------------|----------|----------|----------|----------|----------------|
File           |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
---------------|----------|----------|----------|----------|----------------|
All files      |    19.44 |     1.54 |    11.11 |       20 |                |
 drupal.es6.js |    19.44 |     1.54 |    11.11 |       20 |... 573,574,588 |
---------------|----------|----------|----------|----------|----------------|

There are many things to fix, like mocking the browser env, fixing scripts so that mocking isn't needed, excluding vendor code from code coverage, a way to compile es6 files on the fly for testing, etc.

But it's a start.

Comments

nod_ created an issue. See original summary.

dawehner’s picture

Should we mark #2702747: Add javascript unit testing as a duplicate?

nod_’s picture

Oh right, forgot that one. Na this one has less people watching, I'll update the other one and merge the two, you already fixed some todos I have.

nod_’s picture

reroll -all is the diff with my es6 branch, the stuff needed to do the testing is in the small patch.

Still need to get around to merging the two patches.

nod_’s picture

The last submitted patch, 4: core-es6-testing-2815199-4.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 5: core-es6-testing-2815199-4.patch, failed testing.

nod_’s picture

Status: Needs work » Needs review
m1r1k’s picture

Have added couple packages to work with $, ajax, drupal anonymous functions, etc.
Also another example of test.

m1r1k’s picture

I am not sure how to properly use jsdom-global for now, may be we could erase most of the code in boostrap.js file :)

Also what do you think about splitting js files on API files and actual files with behaviors?

Drupal object itself, Drupal.ProgressBar, Drupal.debounce, Drupal.Ajax*, etc. We could something like npm package with API js files.

nod_’s picture

woot, thanks a lot.

I don't remember if there is a dedicated issue yet but it is certainly planned to separate library code from behaviors. And more than that, make sure all the behavior object have only a attach and detach property, nothing else (otherwise it should be a dedicated library).

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dawehner’s picture

One part we should take into account in this issue is whether / how to deal with javascript functional testing. At least for now a lot of javascript functional test coverage is missing, and I'm wondering whether moving that to JS would help. In case we decide that we should take into account and probably use a testing framework which can handle both.

There are probably many systems out there, of which one is Nightwatch.

This raises a couple of questions:

  • Do we want the functional JS tests in JS or in PHP?
  • Would be attract more JS people by not force them to write PHP?
  • Would it be a disadvantage to have two systems to write tests in when you want to contribute to Drupal on both PHP and JS?
drpal’s picture

#13

One part we should take into account in this issue is whether / how to deal with javascript functional testing.

Yes.

At least for now a lot of javascript functional test coverage is missing, and I'm wondering whether moving that to JS would help.

It would possibly make it easier for people who know minor bits about PHP to write functional tests for JavaScript components.

Do we want the functional JS tests in JS or in PHP?

In JavaScript.

Would be attract more JS people by not force them to write PHP?

Yes.

Would it be a disadvantage to have two systems to write tests in when you want to contribute to Drupal on both PHP and JS?

Possibly?, but probably only briefly.

michielnugter’s picture

I've been thinking a bit about this and I'll just share my view on this. Do note that I'm relatively new to Drupal and testing such a system but have more experience in projects for work with a QA specialist. I have been quite active in the PHPUnit initiative in the last couple of months so I do feel that it's useful to share my view :)

So what are we actually testing?
We say and assume we're testing JavaScript with the JavaScriptTestBase tests, I'm not 100% sure on that though. Why? We're still doing functional tests, but this time in a real browser instead of a simulated one. I think that we should therefore look at this differently, don't focus on JavaScript but on implementing real-world tests, that's what we're trying to do.

The reason why we need it is still the same, a simulated browser is not enough for testing rich user interfaces that utilize browser functions like JavaScript or CSS.

The question then is how to test it
Currently we’re running tests in PHP, which to me is fine because the other functional testing (BrowserTestBase) is PHP as well. This way we have a similar environment for both types of test and it’s easy to move a BrowserTestBase to JavascriptTestBase.

To me functional testing in JavaScript doesn’t feel right (yet?), to me we'll only move the responsibility to an area where we have even less people interested in functional testing. I'm not convinced either that it's better to functional test in JavaScript and that deep JavaScript knowledge is required to do it.

To clarify and prevent any misunderstandings: I do agree on needing unit tests in Javascript and I like the direction for this in this issue :)

Another option would be to use Selenium for these kinds of test (I think this was discussed in #825436: Create selenium-RC PIFR plugin for full functional testing but rejected at the time). I'm not very familiar with Selenium but it is a much used tool for functional testing by the QA specialist. It would actually open up a whole new way of contributing to Drupal for QA specialist. Writing PHP is difficult for them but Selenium tests are well within their comfort zone. It would still cause a split in how functional tests are written though with BrowserTests.

dawehner’s picture

I opened up an issue about leveraging nightwatch for functional test coverage on #2869825: Experiment: Get nightwatch working to functional test Drupal JS via JS