{"id":15559105,"url":"https://github.com/alexlafroscia/qunit-wait-for","last_synced_at":"2025-04-23T21:10:18.446Z","repository":{"id":37095805,"uuid":"251495981","full_name":"alexlafroscia/qunit-wait-for","owner":"alexlafroscia","description":"Wait for a QUnit Assertion","archived":false,"fork":false,"pushed_at":"2025-03-03T11:40:23.000Z","size":929,"stargazers_count":12,"open_issues_count":12,"forks_count":2,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-04-19T03:56:26.750Z","etag":null,"topics":["ember","emberjs","qunit","testing"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","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/alexlafroscia.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","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":"2020-03-31T03:58:22.000Z","updated_at":"2024-08-31T17:19:34.000Z","dependencies_parsed_at":"2022-06-24T13:24:22.923Z","dependency_job_id":"85a93409-c593-443a-99a5-4e9454f1c798","html_url":"https://github.com/alexlafroscia/qunit-wait-for","commit_stats":null,"previous_names":[],"tags_count":10,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexlafroscia%2Fqunit-wait-for","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexlafroscia%2Fqunit-wait-for/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexlafroscia%2Fqunit-wait-for/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexlafroscia%2Fqunit-wait-for/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/alexlafroscia","download_url":"https://codeload.github.com/alexlafroscia/qunit-wait-for/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250514789,"owners_count":21443209,"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":["ember","emberjs","qunit","testing"],"created_at":"2024-10-02T15:41:43.102Z","updated_at":"2025-04-23T21:10:18.427Z","avatar_url":"https://github.com/alexlafroscia.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# `qunit-wait-for`\n\n![Verify](https://github.com/alexlafroscia/qunit-wait-for/workflows/Verify/badge.svg)\n\n\u003e Wait for a QUnit Assertion\n\n## Installation\n\nInstall the dependency:\n\n```\nyarn add -D qunit-wait-for\n```\n\nand then add the following in your JavaScript code:\n\n```javascript\nimport QUnit from \"qunit\";\nimport { installWaitFor } from \"qunit-wait-for\";\n\ninstallWaitFor(QUnit);\n```\n\nIf you're using Ember, the right place for that snippet is your `tests/test-helper.js`.\n\n## What does it do?\n\nA common pattern in UI testing is the idea of needing to wait for some condition to be met before moving on in your tests. Normally we do some setup, interact with our application, wait for some event to take place, and then perform our assertions. For example, you might see something like this in an Ember integration test:\n\n```javascript\n// Start with some modal rendered\nawait render(hbs`\u003cModalDialog /\u003e`);\n\n// Close the modal, which might need time to animate off-screen\nawait click(\"[data-test-close-button]\");\n\n// Wait for the modal to actually be gone\nawait waitUntil(() =\u003e findAll(\"[data-test-modal-element]\").length === 0);\n\n// Actually _assert_ that the modal is gone\nassert.dom(\"[data-test-modal-element\").doesNotExist();\n```\n\nMany testing libraries provide helper functions to wait for your tests to catch up to the desired state:\n\n- In Ember, there are many test helpers that serve this purpose; `waitUntil`, `settled`, and `await`-ing the promise returned from other test helpers all serve this purpose\n- In React, the [async utilities from `@testing-library/dom`](https://testing-library.com/docs/dom-testing-library/api-async) provide this functionality\n\nHowever, needing to know when -- and how -- to correctly wait for the UI under test to reach the right state adds complexity to your tests and can couple them tightly to the underlying implementation of the code being tested.\n\nThere's another approach that you can take that's much cleaner; rather than waiting for your tests to reach some state and then asserting against it, you can let your assertions run immediately and gracefully handle an initial failure. Then, try the assertion again, over and over until it passes (or a timeout is reached). I call this pattern \"convergence testing\" based on work from [The Frontside](https://frontside.io) on [BigTest.js](https://bigtestjs.io). The result is a test that both correctly waits for asynchronous operations to complete _and_ is decoupled from specific logic around _how_ to wait for the right state.\n\nWith `qunit-wait-for`, the example above can be simplified to this:\n\n```javascript\nawait render(hbs`\u003cModalDialog /\u003e`);\n\nawait click(\"[data-test-close-button]\");\n\nawait assert.waitFor(() =\u003e {\n  assert.dom(\"[data-test-modal-element\").doesNotExist();\n});\n```\n\n## Usage\n\nTo use it, pass a callback to `assert.waitFor` and within it place your normal assertion:\n\n```javascript\nawait assert.waitFor(() =\u003e {\n  assert.dom(\"[data-test-my-element]\").exists();\n});\n```\n\nThe resulting promise resolves when either the condition is met or the timeout is reached. This promise should always be `await`-ed so ensure one of those two things has happened before moving on.\n\nYou can also provide an override for the amount of time to wait for the assertion to pass, if needed. By default it will wait for up to 1000ms (1 second):\n\n```javascript\n// Wait for up to 2 seconds instead of 1\nawait assert.waitFor(\n  () =\u003e {\n    assert.dom(\"[data-test-my-element]\").exists();\n  },\n  { timeout: 2000 }\n);\n```\n\n## Prior Art\n\n- [Converging on a Condition in QUnit](https://alexlafroscia.com/qunit-assert-converge-on/)\n\n  A blog post I wrote a while ago, describing a similar API that was not based on using a normal assertion to test that the condition has been met\n\n- [`waitFor` from `@testing-library/dom`](https://testing-library.com/docs/dom-testing-library/api-async#waitfor)\n\n  Inspired the API of this library, where you also pass a callback that performs an otherwise normal test assertion\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falexlafroscia%2Fqunit-wait-for","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falexlafroscia%2Fqunit-wait-for","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falexlafroscia%2Fqunit-wait-for/lists"}