WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 7 months ago

#25096 closed task (blessed) (fixed)

Automate running JavaScript unit tests with Grunt

Reported by: kadamwhite Owned by:
Milestone: 3.7 Priority: normal
Severity: normal Version:
Component: Unit Tests Keywords:
Focuses: Cc:

Description

As discussed in IRC, we are beginning the process of adding JavaScript unit tests. Grunt may be used to automatically run JS unit tests from the command line, shortening the develop-test feedback cycle. This patch adds a Grunt task to run QUnit-based tests like the ones being worked on in #25088.

Install this patch alongside #25088, run npm install to install the QUnit plugin for Grunt, then run tests with grunt test.

I am in the process of enhancing this to also provide an option to run tests in a local web server, in order to get more visual feedback, permit running tests in multiple browsers, and/or use browser development tools while writing tests.

Attachments (4)

25096.diff (1.4 KB) - added by kadamwhite 8 months ago.
Basic QUnit task to run test spec HTML files in tests/qunit from the command line
25096.1.diff (1.9 KB) - added by kadamwhite 8 months ago.
QUnit tasks to run specs from the command line, or in a browser (supporting LiveReload)
25096.2.diff (1.4 KB) - added by jorbin 8 months ago.
25096.3.diff (1.1 KB) - added by jorbin 7 months ago.

Download all attachments as: .zip

Change History (25)

kadamwhite8 months ago

Basic QUnit task to run test spec HTML files in tests/qunit from the command line

kadamwhite8 months ago

QUnit tasks to run specs from the command line, or in a browser (supporting LiveReload)

comment:1 kadamwhite8 months ago

Uploaded another patch to add in the grunt-contrib-connect task, which can be used to start a local webserver so developers can load the tests in a web browser. After talking with jorbin we don't automatically open up a web browser, in order to give the developer the flexibility to run from the command line or not, but these are now the tasks available:

  • grunt test: Run all available QUnit specs on the command line, and exit
  • grunt watch:test: Run all available QUnit specs on the command line, and re-run specs whenever any HTML or JS files within /tests/qunit change
  • grunt test:debug: Start a local webserver at http://localhost:8000/, then start watch:test: If you visit http://localhost:8000/tests/qunit/ and activate LiveReload e.g. with a browser extension, the browser will auto-refresh the tests page whenever test files change.
Last edited 8 months ago by kadamwhite (previous) (diff)

comment:2 jorbin8 months ago

  • Cc jorbin added

comment:3 kadamwhite8 months ago

  • Cc kadamwhite@… added

comment:4 jeremyfelt8 months ago

Is there language we can use to imply that options are available other than localhost in grunt.log.writeln('Run tests in a browser at http://localhost:8000/tests/qunit/');? I know it's a bit of a stretch, but it looks like the config listens to all IPs on port 8000 and it would be cool to find a way to say so.

comment:5 kadamwhite8 months ago

Note that an alternative to requiring a browser extension would be to include <script src="http://localhost:35729/livereload.js"></script> at the bottom of the test spec HTML files, which will automatically bind the page to reload on changes even without having to install anything.

comment:6 adamsilverstein8 months ago

  • Cc adamsilverstein@… added

comment:7 carldanley8 months ago

  • Cc carldanley@… added

comment:9 WraithKenny8 months ago

  • Cc Ken@… added

comment:10 adamsilverstein8 months ago

works great, thanks - great start!

comment:11 nacin8 months ago

#24870 was marked as a duplicate.

comment:12 nacin8 months ago

In 25178:

Add grunt test task for QUnit tests.

props kadamwhite.
see #25096.

comment:13 nacin8 months ago

  • Milestone changed from Awaiting Review to 3.7

Anything else that needs to happen here?

jorbin8 months ago

comment:14 jorbin8 months ago

I added a debug task that also starts a simple server. I think that it will be very common that people won't have a server setup to point to the qunit directory and this will enable them to simply run the unit tests in a browser.

This is based on the code kadamwhite wrote earlier as a part of 25096.1.diff

jorbin7 months ago

comment:15 jorbin7 months ago

Patch refreshed based on our addition of matchdep

comment:16 follow-up: nacin7 months ago

Is the purpose of the watch task in 25096.3.diff to keep grunt running, and thus the server connection open? Seems like that is the case, just want to double-check.

comment:17 follow-up: nacin7 months ago

For what it's worth, I don't think it is unreasonable to expect that people will have a web server. But even then, won't file: will work here since it is just JS? For example, file:///Users/nacin/Sites/develop/tests/qunit/index.html.

comment:18 in reply to: ↑ 16 jorbin7 months ago

Replying to nacin:

Is the purpose of the watch task in 25096.3.diff to keep grunt running, and thus the server connection open? Seems like that is the case, just want to double-check.

Yes, that is correct.

comment:19 in reply to: ↑ 17 jorbin7 months ago

Replying to nacin:

For what it's worth, I don't think it is unreasonable to expect that people will have a web server. But even then, won't file: will work here since it is just JS? For example, file:///Users/nacin/Sites/develop/tests/qunit/index.html.

Unreasonable, no. Unlikely, yes. File should work. The one problem is that I don't think it would easily allow for the addition of a livereload script to make debugging even easier.

comment:20 nacin7 months ago

  • Type changed from enhancement to task (blessed)

comment:21 nacin7 months ago

  • Resolution set to fixed
  • Status changed from new to closed

Let's hold off on http://core.trac.wordpress.org/attachment/ticket/25096/25096.3.diff until we have started to ramp up on the number of JS tests. Right now our qUnit tests are little more than a proof of concept. So let's avoid adding an extra dependency for now. No need to get ahead of ourselves. Could be timed with liveReload support, for example.

Note: See TracTickets for help on using tickets.