Ui5 Best Practices Qunit

by UI5a99b882ce364No licenseListed Oct 8, 2026Updated Oct 8, 2026

Use when the user asks to "write a QUnit test", "fix a failing QUnit test", "add a QUnit module", "modernize QUnit tests", "migrate from QUnit 1", or mentions QUnit-specific constructs such as assert.async, nextUIUpdate, Core.applyChanges, sinon sandbox, asyncTest, or QUnit.module. Covers coding standards for OpenUI5/SAPUI5 unit test files: const/let over var, arrow functions over .bind(this), async/await over assert.async(), assert.expect() in every async test, sinon.createSandbox(), descriptive test names, beforeEach/afterEach module isolation, nextUIUpdate vs Core.applyChanges rules, try/finally teardown in helpers, QUnit 1 to QUnit 2 globals migration, and non-ASCII character avoidance.

Instructions onlySoftware Development
AI-generated overview

Coding standards for writing, fixing and modernizing OpenUI5/SAPUI5 QUnit unit tests.

What it does
This skill provides rules and reference guidance for authoring and reviewing QUnit test files in OpenUI5/SAPUI5 projects. It covers style conventions such as const/let over var, arrow functions over .bind(this), async/await over assert.async(), assert.expect() in async tests, sinon.createSandbox(), descriptive test names, beforeEach/afterEach isolation, try/finally teardown, nextUIUpdate versus Core.applyChanges, and QUnit 1 to QUnit 2 migration. It also routes the agent to three bundled reference documents for writing new tests, modernizing existing tests, and async patterns.
When to use it
Use it when asked to write a QUnit test, fix a failing QUnit test, add a QUnit module, modernize or migrate QUnit tests, or when QUnit-specific constructs such as assert.async, nextUIUpdate, Core.applyChanges, sinon sandbox, asyncTest or QUnit.module come up. It is intended for UI5 unit test code rather than application code.
Requirements
No scripts; instructions and three markdown reference files only. The agent should load the relevant reference before producing output. Target projects are expected to use QUnit, Sinon and OpenUI5/SAPUI5 with ESLint.

QUnit Test Best Practices for UI5

When to load each reference

TriggerLoad
Writing a new QUnit test file or module from scratchreferences/writing-new-tests.md [blocked]
Modernizing, refactoring, or reviewing existing test codereferences/modernizing-tests.md [blocked]
Migrating from QUnit 1 (globals: test, asyncTest, ok, stop, start) to QUnit 2references/modernizing-tests.md [blocked]
Any test touches nextUIUpdate, Core.applyChanges, assert.async, fake timers, or event-based asyncreferences/async-patterns.md [blocked]

Load the reference before producing any output. Do not work from memory.


Core rules (always apply)

RuleDetail
No varUse const or let. One declaration per line - no comma chains.
No .bind(this)Use arrow functions for callbacks that do not need their own this.
assert.expect(N) in every async testGuards against silent passes when async callbacks never fire. Not required for sync tests.
sinon.createSandbox()sinon.sandbox.create() emits a runtime deprecation warning in Sinon 5+ - prefer sinon.createSandbox(). Alternatively use the QUnit-sinon bridge (this.stub(), this.spy(), this.mock(); this.clock only when sinon.config.useFakeTimers is truthy). Do not mix both approaches in the same module.
Descriptive test namesSentence describing behavior. Never start with "it should". Unique within each module.
beforeEach / afterEach in every moduleCreate all controls in beforeEach, destroy them in afterEach. No shared mutable state between tests.
try/finally in helper-created controlsHelpers that create a control must destroy it in finally so it is cleaned up even when assertions throw.
No non-ASCII charactersNo non-ASCII characters in comments, strings, or JSDoc. Use plain ASCII hyphens, not em dashes. UTF-8 is required, but non-ASCII in comments has historically caused encoding issues.
ESLint - 0 errorsWarnings for pre-existing patterns (max-nested-callbacks, no-use-before-define, valid-jsdoc) are acceptable.

Quick-reference checklist

Use when authoring or reviewing a QUnit test file:

  • No var - use const or let; one declaration per line (no comma chains)
  • No .bind(this) - use arrow functions for callbacks that do not need their own this
  • No assert.async() in simple cases - use async function + await new Promise(...)
  • Every async test has assert.expect(N)
  • No sinon.sandbox.create() in new code - use sinon.createSandbox() or the bridge (this.stub(), this.spy(), this.mock()); this.clock only when fake timers are enabled
  • No "it should..." test titles - use descriptive sentences
  • Every QUnit.module has beforeEach / afterEach that create and destroy all controls
  • With fake timers: prefer await nextUIUpdate(this.clock) over Core.applyChanges(); only keep Core.applyChanges() when nextUIUpdate(clock) cannot handle the case
  • Helper functions that create controls destroy them in try/finally
  • No non-ASCII characters in comments or strings (UTF-8 required, but non-ASCII causes encoding issues)

Source and attribution

Source:UI5/plugins-coding-agentsinplugins/ui5/skills/ui5-best-practices-qunitat commita99b882

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

Ui5 Best Practices Qunit Agent Skill | SourceWeft