{"id":18573805,"url":"https://github.com/ingenerator/qunit-runner","last_synced_at":"2026-04-30T09:31:35.480Z","repository":{"id":151208974,"uuid":"170575598","full_name":"ingenerator/qunit-runner","owner":"ingenerator","description":"Docker QUnit test runner based on Puppeteer / Chrome (headless)","archived":false,"fork":false,"pushed_at":"2021-05-06T10:24:39.000Z","size":104,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":4,"default_branch":"0.1","last_synced_at":"2025-03-05T02:02:05.362Z","etag":null,"topics":["builder","docker","gcb","qunit"],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ingenerator.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-02-13T20:35:10.000Z","updated_at":"2021-05-06T10:25:07.000Z","dependencies_parsed_at":null,"dependency_job_id":"35ead01e-8746-4ed0-a79e-4eb3e681b7cf","html_url":"https://github.com/ingenerator/qunit-runner","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ingenerator%2Fqunit-runner","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ingenerator%2Fqunit-runner/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ingenerator%2Fqunit-runner/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ingenerator%2Fqunit-runner/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ingenerator","download_url":"https://codeload.github.com/ingenerator/qunit-runner/tar.gz/refs/heads/0.1","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254442321,"owners_count":22071863,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["builder","docker","gcb","qunit"],"created_at":"2024-11-06T23:12:47.501Z","updated_at":"2026-04-30T09:31:30.458Z","avatar_url":"https://github.com/ingenerator.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# QUnit Test Runner\n\nA minimal Alpine-based Docker image with Node and Puppeteer\nspecifically built to run QUnit test suites. The container relies upon\n[light-server](https://www.npmjs.com/package/light-server) to host\nthe contents of /workspace while\n[Puppeteer](https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md#running-puppeteer-in-docker)\noperates Google Chrome to run the QUnit test suite\n\n### Running with an asset manifest JSON\n\nStandard usage is to run the builder using an asset-manifest.json which defines the source javascripts,\ntest libraries and test suites. A test suite is defined with a directory of test files, to ensure that all tests are \nincluded and executed.\n\nYou can see an example of an asset-manifest.json in the integration tests for this image at \n[tests/integration/manifest-json/tests/asset-manifest.json](tests/integration/manifest-json/tests/asset-manifest.json).\n\nThe expectation is you would feed this asset-manifest.json to your asset compile step, so you use\na single definition to specify all the javascript sources that make up your production compiled JS\nfile(s) and the related test suites.\n\n#### named test suites\n\nYou can have as many different qunit suites as you require - generally, one per eventual compiled \nproduction JS file would be sensible.\n\nIn the common case where you have a single JS for the whole application, you would have a single suite. This suite would \ntest all the components of the production JS in a single pass - this ensures the tests pick up any conflicts between \nclasses/functions/global state etc defined in different modules:\n\n```\n{\n  \"js\": {\n     \"compile\": {\n       \"htdocs/compiled/widgets.com.min.js\": {\"sources\": [\"vendor/dependency.js\", \"application/js/module.js\"]}\n     },\n     \"qunit_suites\": [\n       {\n         \"name\": \"widgets.com\",\n         \"test_dirs\": [\"application/js/tests\"],\n         \"compiled_sources\": [\"htdocs/compiled/widgets.com.min.js\"]\n         // qunit ver, libraries, etc\n       }\n     ]\n  }\n}\n```\n\nIf you serve different / additional JS in some cases - e.g. for a CMS backend, administrative users, or a widget \nembedded on other sites - you would create a suite for each JS execution context, named appropriately. If the JS \noverlaps at runtime, you may wish to similarly make your suites overlap to pick up any conflicts:\n\n```\n{\n  \"js\": {\n     \"compile\": {\n       \"htdocs/compiled/public-users.min.js\": {\"sources\": [\"vendor/dependency.js\", \"application/js/site.js\"]},\n       \"htdocs/compiled/admin-users.min.js\": {\"sources\": [\"vendor/dependency.js\", \"application/js/admin.js\"]}\n     },\n     \"qunit_suites\": [\n       {\n         \"name\": \"public\",\n         \"test_dirs\": [\"application/js/site/tests\"],\n         \"compiled_sources\": [\"htdocs/compiled/public-users.min.js\"]\n         // qunit ver, libraries, etc\n       },\n       {\n         \"name\": \"admin\",\n         \"test_dirs\": [\"application/js/site/tests\", \"application/js/site/admin/tests\"],\n         \"compiled_sources\": [\"htdocs/compiled/public-users.min.js\", \"htdocs/compiled/admin-users.min.js\"]\n         // qunit ver, libraries, etc\n       }\n     ]\n  }\n}\n```\n\n**Note**: if you have multiple suites you must run each one separately : the runner does not support executing multiple\nsuites in a single pass, due to the complexity of capturing and reporting the success/failure status.\n\n#### `-compiled` and `-sources` test runners\n\nWhen you run the image with an asset manifest, it builds two standard qunit execution HTML files for\neach defined test suite:\n\n* `qunit-{suite-name}-compiled.html` - this includes the qunit runner, any required test-environment libraries, \n  the requested compiled production JS files (which must already exist) and the test files from the specified\n  directory(/ies).\n\n* `qunit-{suite-name}-sources.html` - this includes the same test environment as the `-compiled` file. However,\n  it uses the asset manifest to identify and include the individual source files that would be compiled\n  into the production JS. This allows you to run and rerun tests in the local development environment without \n  having to recompile your javascript after every change.\n  \nIn the non-interactive mode (`test` command) the runner will execute and report the status of the \n`-compiled` file. In a local environment you can run either of the provided HTML endpoints (see below).\n\n#### Including libraries\n\nThis image carries several useful qunit helper libraries, including lolex, sinon.js and jquery-mockjax.\nSee the [libs](libs/) directory to browse the full set. The internal http server exposes these over HTTP \nat `/libraries`. To use them in a test suite, just add the relative path to the `libraries` array. The \ncompiler will render the qunit HTML with the URL to the local copy, to reduce network and project \ndependencies in your tests.\n\nAlternatively, you can specify any additional libraries / versions by their HTTP(s) URL and they will \nbe included over the network.\n\nFor example:\n\n```\n{ \n  \"js\": {\n    // other stuff here\n    \"qunit_suites\": [\n      {\n        \"name\": \"application\",\n         // other stuff\n         \"libraries\": [\n           \"lolex/4.1.0/lolex.js\",\n           \"http://some.cdn/my-custom-mockjax/5.02.js\"\n         ]\n      }\n    ]\n  } \n}\n```  \n\nCurrently the specified qunit and jquery versions are loaded from external CDN, but they may be baked into\nthe image in future. \n\n### Running in Google Cloud Build\n\nJust add this step to your cloudbuild.yaml\n\n```yaml\nsteps:\n    - name: 'eu.gcr.io/ingenerator-ci/qunit-runner'\n    - args: ['test', 'asset-manifest.json', '{suite-name}']\n```\n\nYou don't need to worry about mounting volumes as GCB automatically\nmounts the workspace into /workspace of every step.\n\nNote : *the default behaviour is to run the older-style process*, where the application is assumed to\nhave a pre-compiled qunit runner committed at `application/assets/js/tests/qunit_compiled.html`. This \napproach still works, but is deprecated in favour of the newer asset-manifest approach.\n\n### Running tests locally via CLI\n\n```bash\ndocker run  --cap-add=SYS_ADMIN --rm -it \\\n            -v $PWD:/workspace \\\n            eu.gcr.io/ingenerator-ci/qunit-runner \\\n            test asset-manifest.json {suite-name}\n```\n\n### Running test suite in the browser\n\n```bash\ndocker run  --cap-add=SYS_ADMIN --rm -it \\\n            -v $PWD:/workspace \\\n            -p 8000:8000 \\\n            eu.gcr.io/ingenerator-ci/qunit-runner \\\n            dev asset-manifest.json\n```\n\nand then navigate to `http://localhost:8000/qunit-{suite-name}-{compiled|sources}.html`\n\n\u003e **Note**: Currently it will live reload the page on changes to *.html and *.js files\nhowever this behaviour may or may not work through a docker mounted volume\non certain host operating systems. Suggestions / pull-requests welcome (or just keep mashing refresh) :)\n\n---\n\n#### Tips\n\nSeeing other weird errors when launching Chrome? Try running your\ncontainer with docker run --cap-add=SYS_ADMIN when developing locally.\nSince the Dockerfile adds a pptr user as a non-privileged user, it may\nnot have all the necessary privileges.\n\nThere is a lot of useful advice at https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md#running-puppeteer-in-docker\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fingenerator%2Fqunit-runner","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fingenerator%2Fqunit-runner","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fingenerator%2Fqunit-runner/lists"}