Ui5 Best Practices Qunit

QUnit Test Best Practices for UI5

When to load each reference

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

---

Core rules (always apply)

---

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)