From b0da0b6d2d8f3ff110acd6abe92267784dd07644 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 14:15:26 -0400
Subject: [PATCH 01/11] Prose updates

---
 text/1203-deprecate-get-set-test-context.md | 163 ++++++++++++++------
 1 file changed, 116 insertions(+), 47 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index cb29c01e43..d53e11a5c6 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -12,29 +12,63 @@ prs:
 project-link:
 ---
 
-# Deprecate `this.get` and `this.set` on Test Contexts
+# Deprecate `get`, `set`, `getProperties`, and `setProperties` on test contexts
 
 ## Summary
 
-Deprecate the use of `this.get` and `this.set` on the test context object in rendering tests, as a logical conclusion of [RFC #785](https://github.com/emberjs/rfcs/blob/master/text/0785-remove-set-get-in-tests.md), which introduced `render(component)` and `rerender()` as the modern replacements.
+Deprecate the four data-manipulation methods that `@ember/test-helpers` installs on the test context: `this.get`, `this.set`, `this.getProperties`, and `this.setProperties`. Everything else the test context provides is untouched: `this.owner`, `this.element`, `this.pauseTest`, `this.resumeTest`, and properties you assign yourself.
 
 ## Motivation
 
-RFC #785 introduced two new testing utilities — an updated `render` helper that accepts a component directly, and a new `rerender()` function — specifically to remove the need for `this.get` and `this.set` in rendering tests. Those APIs shipped in Ember v4.5.0 and are now the recommended approach for writing rendering tests.
+[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) made the case against these methods five years ago and shipped the replacements: `render` learned to accept a component, and `rerender` was added alongside it, in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from the `@ember/renderer` module that landed in `ember-source` 4.5.0. What that RFC did not do was set an end date for the old way. This one does.
 
-The legacy pattern of setting values on `this` in a rendering test was problematic for several reasons laid out in RFC #785:
+The arguments have not changed since #785, so they are worth restating only briefly. `get` and `set` are not how anyone writes application code after Octane, so tests written this way are teaching a model that exists nowhere else. Stashing template state on `this` means TypeScript users have to widen `TestContext` per module, and those widenings then appear to apply to every test in the module whether or not the property is actually there. And the test context doing double duty, as both test harness *and* backing object for the template, is just hard to explain.
 
-1. **Inconsistency with application code.** In post-Octane Ember, `get` and `set` are unnecessary; properties are tracked natively. Requiring them in tests is a confusing holdover.
+There is one newer argument. `this.set` and `this.setProperties` are `run()`-wrapped:
 
-2. **Incorrect rendering semantics.** `this.set` in tests is run-wrapped, causing a synchronous full DOM flush on every call. This does not reflect how Ember schedules DOM updates in production code, where changes to tracked state are coalesced.
+```js
+Object.defineProperty(context, 'setProperties', {
+  value(hash) {
+    return run(function () {
+      return setProperties(context, hash);
+    });
+  },
+  // ...
+});
+```
 
-3. **TypeScript friction.** Assigning arbitrary properties to `this` forces developers to redeclare the `TestContext` interface for every test module, causing leakage of property declarations across tests and defeating the purpose of static type checking.
+Every call synchronously flushes the entire DOM. Nothing in an application behaves this way; there, updates to tracked state coalesce into one render pass. That synchronous flush is also precisely the behavior that a render-aware scheduler ([RFC #957](https://github.com/emberjs/rfcs/pull/957)) cannot preserve. To be clear: this deprecation is not a prerequisite for that work. A test that already avoids these methods can adopt an async scheduler as-is. But every test that still calls `this.set` is a test that will have to be rewritten when the scheduler changes, and it is better to rewrite it against a deprecation with a migration guide than against a scheduler change.
 
-Now that the modern replacements have been stable for multiple major versions, it is appropriate to deprecate the old approach and eventually remove it, completing the migration to a cleaner and more accurate testing model.
+Note that `get` and `getProperties` are not `run()`-wrapped. They are thin wrappers over `get`/`getProperties` from `@ember/object` applied to the context. They are included here because they exist only to read back what `set` wrote, and keeping them after `set` is gone serves no one.
 
 ## Transition Path
 
-### Before (deprecated)
+### What is deprecated
+
+`setupContext` from `@ember/test-helpers` installs `get`, `set`, `getProperties`, and `setProperties` on the context. All four are deprecated. Because they come from `setupContext` and not `setupRenderingContext`, they are present in unit, rendering, and application tests alike, and the deprecation covers all three.
+
+### What is not deprecated
+
+- `this.owner`, which is the whole point of the test context.
+- `this.element`, available in rendering tests. Whether it should exist at all is a separate conversation; this RFC does not have it.
+- `this.pauseTest()` and `this.resumeTest()`, which are useful precisely because you can reach for them mid-debug without editing your imports.
+- Assigning your own properties to `this`. `this.foo = someValue` is a common pattern for sharing setup between hooks and tests and remains supported.
+
+That last point has a consequence worth spelling out, because it is easy to misread this RFC as doing more than it does. `render` installs the test context as the rendered outlet's `controller`, which is what makes `{{this.name}}` in an `hbs` template resolve against the test context. Deprecating these four methods does not remove that binding:
+
+```js
+// still works after this deprecation
+this.name = 'Zoey';
+await render(hbs`{{this.name}}`); // renders "Zoey"
+
+this.name = 'Tomster';
+await rerender();
+assert.dom().hasText('Zoey'); // ...and still "Zoey"
+```
+
+The initial render picks the value up; the reassignment does nothing, because the property is not tracked and nothing is `run()`-wrapping the write. Severing the template-to-context binding is a larger, separate change and needs its own RFC.
+
+### Before
 
 ```js
 import { render } from '@ember/test-helpers';
@@ -45,24 +79,27 @@ test('it renders the name', async function (assert) {
 
   await render(hbs`<MyComponent @name={{this.name}} />`);
 
-  assert.dom('[data-test-name]').hasText(this.get('name'));
+  assert.dom('[data-test-name]').hasText('Zoey');
 
   this.set('name', 'Tomster');
 
-  assert.dom('[data-test-name]').hasText(this.get('name'));
+  assert.dom('[data-test-name]').hasText('Tomster');
 });
 ```
 
-### After (recommended)
+### After
 
 ```js
 import { render, rerender } from '@ember/test-helpers';
 import { tracked } from '@glimmer/tracking';
+import MyComponent from 'my-app/components/my-component';
 
 test('it renders the name', async function (assert) {
-  const state = new class {
+  class State {
     @tracked name = 'Zoey';
-  };
+  }
+
+  const state = new State();
 
   await render(<template><MyComponent @name={{state.name}} /></template>);
 
@@ -75,21 +112,28 @@ test('it renders the name', async function (assert) {
 });
 ```
 
-For projects that have not yet adopted `<template>` tag syntax, `precompileTemplate` from `@ember/template-compilation` can be used together with a scope hash instead:
+The `await rerender()` is new, and it is not optional. `this.set` gave you a synchronous flush for free; a plain assignment to tracked state does not.
+
+Projects not yet on `<template>` can get the same result with `precompileTemplate` and a scope hash. Everything referenced in the template has to be in `scope`, including the component:
 
 ```js
 import { render, rerender } from '@ember/test-helpers';
 import { precompileTemplate } from '@ember/template-compilation';
 import { tracked } from '@glimmer/tracking';
+import MyComponent from 'my-app/components/my-component';
 
 test('it renders the name', async function (assert) {
-  const state = new class {
+  class State {
     @tracked name = 'Zoey';
-  };
+  }
 
-  await render(precompileTemplate('<MyComponent @name={{state.name}} />', {
-    scope: () => ({ state, MyComponent }),
-  }));
+  const state = new State();
+
+  await render(
+    precompileTemplate('<MyComponent @name={{state.name}} />', {
+      scope: () => ({ state, MyComponent }),
+    })
+  );
 
   assert.dom('[data-test-name]').hasText('Zoey');
 
@@ -100,51 +144,76 @@ test('it renders the name', async function (assert) {
 });
 ```
 
-### Deprecation message
+### What to `await`
+
+There are two things to wait on, not three, and the difference between them is the only thing worth teaching here.
 
-When `this.set` or `this.get` is called on the test context, `@ember/test-helpers` should emit a deprecation warning of the form:
+`rerender()` from `@ember/test-helpers` is `renderSettled()` from `@ember/renderer`. The entire implementation is:
 
+```js
+function rerender() {
+  return renderSettled();
+}
 ```
-Using `this.set` / `this.get` on the test context is deprecated.
-Please migrate to passing a component or template with a local tracked state object to `render()`,
-and use `rerender()` to await DOM updates.
-See https://deprecations.emberjs.com/id/test-context-get-set for details.
+
+Use whichever import you find more convenient. `rerender` is the one most tests already import, since it comes from the same module as `render` and `click`; `renderSettled` is the one to reach for in code that has no business depending on `@ember/test-helpers`, such as a library that needs to flush rendering. There is no behavioral difference to document, and the guides should not imply one.
+
+Both resolve when auto-tracked state consumed by the template has been written to the DOM. Neither waits on timers, pending requests, route transitions, or test waiters.
+
+`settled()` waits for all of that: every registered settledness metric, rendering included.
+
+So: after changing tracked state, `await rerender()`. When the assertion depends on work beyond rendering, `await settled()`. The two compose when you want to catch an intermediate state before the slow thing finishes:
+
+```js
+state.isLoading = true;
+await rerender();
+assert.dom('[data-test-status]').hasText('Loading');
+
+await finishLoadingRequest();
+await settled();
+assert.dom('[data-test-status]').hasText('Loaded');
 ```
 
-### Ecosystem considerations
+One implementation detail that surprises people: `render()` itself resolves with `settled()`, not `renderSettled()`. The initial render therefore waits for full settledness regardless of which helper you use afterward.
 
-- **`eslint-plugin-ember`** — A new lint rule (or an update to an existing rule) should be introduced to flag `this.set(…)` and `this.get(…)` calls inside `module(…)` / `test(…)` callbacks, guiding users toward the modern pattern.
-- **Blueprints** — Any existing blueprints in `ember-source` or `ember-cli` that generate rendering-test boilerplate using `this.set`/`this.get` should be updated to use the component-based pattern.
-- **Codemods** — A codemod (e.g. as part of `ember-codemods` or a standalone package) should be provided to automate the majority of the migration. Cases where the test drives complex state that touches multiple `this.set` calls will require manual attention, but simple single-value cases should be fully automatable.
+### Ecosystem
 
-## How We Teach This
+A rule in `eslint-plugin-ember` should flag `this.get`, `this.set`, `this.getProperties`, and `this.setProperties` inside `test()` and hook callbacks. Catching these at lint time rather than at runtime is what makes the migration tractable for the codebases that have the most of them.
 
-The [Testing Components](https://guides.emberjs.com/release/testing/testing-components/) section of the official guides should be updated to:
+Blueprints in `ember-source` and `ember-cli` that still emit `this.set` in generated rendering tests need updating. New apps should not be generating deprecated code on day one.
 
-1. Remove all examples that use `this.set` / `this.get`.
-2. Present the `render(component)` + `rerender()` pattern as the canonical approach.
-3. Include a brief migration note linking to the deprecation guide on `deprecations.emberjs.com`.
+A codemod can handle the mechanical case: a fixed set of `this.set` calls before `render`, with no reassignment afterward. Anything that reassigns mid-test needs a `rerender()` inserted at the right point, and anything with conditional or looped state changes needs a human. The codemod should skip what it cannot do safely rather than guess.
 
-The API docs for `@ember/test-helpers` should likewise be updated to mark `TestContext#set` and `TestContext#get` as deprecated and point to the alternatives.
+`ember-source` and the wider addon ecosystem use these methods heavily in their own test suites and will need migration passes of their own. That is where the codemod earns its keep.
 
-A deprecation guide entry should be added to `deprecations.emberjs.com` covering:
+## How We Teach This
+
+The [Testing Components](https://guides.emberjs.com/release/testing/testing-components/) guide is the main lift. It currently teaches `this.set` as the way to get data into a rendering test, so it needs rewriting rather than patching: local tracked state, `render` with a component or `<template>`, `rerender` after changes. RFC #785 deliberately confined the new pattern to a TypeScript-specific subsection, on the grounds that it was awkward without a way to pass arguments directly. That caveat has aged out. `<template>` is the default authoring format now, and the pattern is no longer TypeScript-specific. It should be taught as *the* way to write a rendering test.
+
+The guides should also make the `rerender` / `settled` distinction explicit, since `this.set`'s synchronous flush is exactly the crutch that hid it. The most common migration bug will be a missing `await rerender()`, and it presents as an assertion against stale DOM.
 
-- What was deprecated and why.
-- The before/after code examples above.
-- Guidance for the less common edge cases (e.g. deeply nested `this.set` calls, helper-heavy templates).
+`@ember/test-helpers` API docs mark all four methods deprecated, pointing at the deprecation guide.
+
+The deprecation guide entry on `deprecations.emberjs.com` covers the four methods, why they are going away, the before/after pair above in both `<template>` and `precompileTemplate` form, the `rerender` requirement after reassignment, and an explicit note that `this.owner`, `this.element`, `this.pauseTest`, and `this.resumeTest` are unaffected. That last item matters because the first question anyone reading a deprecation about "the test context" will ask is whether their `this.owner.lookup` calls are next.
 
 ## Drawbacks
 
-- **Migration cost.** `this.set` and `this.get` have been in use since the beginning of Ember's testing story. Large codebases may have hundreds or thousands of test files that need updating. A well-maintained codemod should substantially reduce the burden.
-- **Loss of a simple entry point.** For simple tests, `this.set('value', x)` is arguably terser than introducing a tracked class. This cost is outweighed by the correctness and TypeScript benefits, but should be acknowledged in migration documentation.
+The migration is large. These methods date to the original testing story, and mature codebases have them in the thousands. A codemod covers the simple shape but not the tests that reassign state, which are the ones worth testing in the first place.
+
+The replacement is more verbose for small tests. `this.set('value', x)` is one line; a tracked class plus an instance is four. That cost is real and it is paid in the tests where it buys the least. The honest defense is that the four lines are the same four lines you would write in application code, and that the one-line version was lying about how rendering works.
+
+Deprecating `get` and `getProperties` is arguably scope creep, since they are not `run()`-wrapped and cause none of the rendering problems. Leaving them would mean shipping a read half of an API whose write half is gone.
 
 ## Alternatives
 
-- **Do nothing.** Leave `this.set` / `this.get` available indefinitely. This leaves the inconsistency and TypeScript friction in place and means RFC #785's goal of a cleaner test model is never fully realized.
-- **Hard removal without a deprecation period.** Would be a breaking change and is not appropriate given how widespread the pattern is.
+Do nothing. The guides keep teaching a model nothing else in Ember uses, and every test that calls `this.set` becomes a problem for whoever lands the render-aware scheduler.
+
+Deprecate everything on the test context except `this.owner`. This was the first shape considered on the PR and it does not survive contact with the details: `this.pauseTest` and `this.resumeTest` are load-bearing for debugging, `this.element` is a separate question, and stashing your own properties on `this` is a legitimate pattern.
+
+Deprecate only `set` and `setProperties`, the two with the rendering problem. Rejected above.
+
+Remove without a deprecation period. Not proportionate to how widespread the pattern is.
 
 ## Unresolved questions
 
-- What is the appropriate Ember version for the deprecation to land in, and what is the target removal version (i.e. the next major)?
-- Should the deprecation be opt-in (gated by a flag in `@ember/test-helpers` config) initially, to allow teams to migrate on their own schedule, before becoming unconditional?
-- Should `this.owner` and other non-`get`/`set` test-context properties remain unaffected? (Yes — this RFC is scoped only to `get` and `set`.)
+None.

From f245709f5b7c13fcdc67a25691422ab03e786156 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 14:25:39 -0400
Subject: [PATCH 02/11] Apply suggestion from @kategengler

Co-authored-by: Katie Gengler <katie@kmg.io>
---
 text/1203-deprecate-get-set-test-context.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index d53e11a5c6..6f39515895 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -16,7 +16,7 @@ project-link:
 
 ## Summary
 
-Deprecate the four data-manipulation methods that `@ember/test-helpers` installs on the test context: `this.get`, `this.set`, `this.getProperties`, and `this.setProperties`. Everything else the test context provides is untouched: `this.owner`, `this.element`, `this.pauseTest`, `this.resumeTest`, and properties you assign yourself.
+Deprecate the four data-manipulation methods that `@ember/test-helpers` installs on the test context: `this.get`, `this.set`, `this.getProperties`, and `this.setProperties`. 
 
 ## Motivation
 

From ce479b814b2df0d134a4bc3719d09734a6f23808 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 14:25:52 -0400
Subject: [PATCH 03/11] Apply suggestion from @kategengler

Co-authored-by: Katie Gengler <katie@kmg.io>
---
 text/1203-deprecate-get-set-test-context.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index 6f39515895..76e9fbadef 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -45,7 +45,7 @@ Note that `get` and `getProperties` are not `run()`-wrapped. They are thin wrapp
 
 ### What is deprecated
 
-`setupContext` from `@ember/test-helpers` installs `get`, `set`, `getProperties`, and `setProperties` on the context. All four are deprecated. Because they come from `setupContext` and not `setupRenderingContext`, they are present in unit, rendering, and application tests alike, and the deprecation covers all three.
+`setupContext` from `@ember/test-helpers` installs `get`, `set`, `getProperties`, and `setProperties` on the context. All four are deprecated. 
 
 ### What is not deprecated
 

From 54874f29494dd122beef880fb564d667344b2115 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 14:30:00 -0400
Subject: [PATCH 04/11] Simplify

---
 text/1203-deprecate-get-set-test-context.md | 128 +++++---------------
 1 file changed, 30 insertions(+), 98 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index 76e9fbadef..f7d3e89d02 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -16,57 +16,30 @@ project-link:
 
 ## Summary
 
-Deprecate the four data-manipulation methods that `@ember/test-helpers` installs on the test context: `this.get`, `this.set`, `this.getProperties`, and `this.setProperties`. 
+Deprecate the four data-manipulation methods that `@ember/test-helpers` installs on the test context: `this.get`, `this.set`, `this.getProperties`, and `this.setProperties`.
 
 ## Motivation
 
-[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) made the case against these methods five years ago and shipped the replacements: `render` learned to accept a component, and `rerender` was added alongside it, in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from the `@ember/renderer` module that landed in `ember-source` 4.5.0. What that RFC did not do was set an end date for the old way. This one does.
+[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) made the case against these methods and shipped the replacements: `render` accepting a component, and `rerender`, in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from `@ember/renderer` in `ember-source` 4.5.0. It did not set an end date for the old way. This one does.
 
-The arguments have not changed since #785, so they are worth restating only briefly. `get` and `set` are not how anyone writes application code after Octane, so tests written this way are teaching a model that exists nowhere else. Stashing template state on `this` means TypeScript users have to widen `TestContext` per module, and those widenings then appear to apply to every test in the module whether or not the property is actually there. And the test context doing double duty, as both test harness *and* backing object for the template, is just hard to explain.
+The reasons from #785 still hold. `get` and `set` are not how application code is written after Octane. Storing template state on `this` forces TypeScript users to widen `TestContext` per module, and those widenings then appear to apply to every test in it. And a test context that is both harness and template backing object is hard to teach.
 
-There is one newer argument. `this.set` and `this.setProperties` are `run()`-wrapped:
+One reason is newer. `set` and `setProperties` are `run()`-wrapped, so each call synchronously flushes the DOM, where an application coalesces updates into a single render pass. That flush is also what a render-aware scheduler ([RFC #957](https://github.com/emberjs/rfcs/pull/957)) cannot preserve. This deprecation is not a prerequisite for that work, since tests avoiding these methods can adopt an async scheduler today. But every remaining `this.set` is a test that will need rewriting when the scheduler lands, and a deprecation with a migration guide is a better place to do that.
 
-```js
-Object.defineProperty(context, 'setProperties', {
-  value(hash) {
-    return run(function () {
-      return setProperties(context, hash);
-    });
-  },
-  // ...
-});
-```
-
-Every call synchronously flushes the entire DOM. Nothing in an application behaves this way; there, updates to tracked state coalesce into one render pass. That synchronous flush is also precisely the behavior that a render-aware scheduler ([RFC #957](https://github.com/emberjs/rfcs/pull/957)) cannot preserve. To be clear: this deprecation is not a prerequisite for that work. A test that already avoids these methods can adopt an async scheduler as-is. But every test that still calls `this.set` is a test that will have to be rewritten when the scheduler changes, and it is better to rewrite it against a deprecation with a migration guide than against a scheduler change.
-
-Note that `get` and `getProperties` are not `run()`-wrapped. They are thin wrappers over `get`/`getProperties` from `@ember/object` applied to the context. They are included here because they exist only to read back what `set` wrote, and keeping them after `set` is gone serves no one.
+`get` and `getProperties` cause none of this. They are included because they exist to read back what `set` wrote.
 
 ## Transition Path
 
-### What is deprecated
-
-`setupContext` from `@ember/test-helpers` installs `get`, `set`, `getProperties`, and `setProperties` on the context. All four are deprecated. 
+`setupContext` from `@ember/test-helpers` installs `get`, `set`, `getProperties`, and `setProperties` on the context. All four are deprecated.
 
 ### What is not deprecated
 
 - `this.owner`, which is the whole point of the test context.
 - `this.element`, available in rendering tests. Whether it should exist at all is a separate conversation; this RFC does not have it.
-- `this.pauseTest()` and `this.resumeTest()`, which are useful precisely because you can reach for them mid-debug without editing your imports.
-- Assigning your own properties to `this`. `this.foo = someValue` is a common pattern for sharing setup between hooks and tests and remains supported.
-
-That last point has a consequence worth spelling out, because it is easy to misread this RFC as doing more than it does. `render` installs the test context as the rendered outlet's `controller`, which is what makes `{{this.name}}` in an `hbs` template resolve against the test context. Deprecating these four methods does not remove that binding:
-
-```js
-// still works after this deprecation
-this.name = 'Zoey';
-await render(hbs`{{this.name}}`); // renders "Zoey"
-
-this.name = 'Tomster';
-await rerender();
-assert.dom().hasText('Zoey'); // ...and still "Zoey"
-```
+- `this.pauseTest()` and `this.resumeTest()`, useful precisely because you can reach for them mid-debug without editing your imports.
+- Assigning your own properties to `this`, a common pattern for sharing setup between hooks and tests.
 
-The initial render picks the value up; the reassignment does nothing, because the property is not tracked and nothing is `run()`-wrapping the write. Severing the template-to-context binding is a larger, separate change and needs its own RFC.
+`render` binds the test context as the rendered template's backing object, which is what makes `{{this.name}}` resolve against it. This RFC does not change that binding, so `this.name = 'Zoey'` before `render` still renders "Zoey"; it just will not update on reassignment. Severing the binding needs its own RFC.
 
 ### Before
 
@@ -112,57 +85,23 @@ test('it renders the name', async function (assert) {
 });
 ```
 
-The `await rerender()` is new, and it is not optional. `this.set` gave you a synchronous flush for free; a plain assignment to tracked state does not.
+The `await rerender()` is not optional. `this.set` gave you a synchronous flush; assigning to tracked state does not.
 
-Projects not yet on `<template>` can get the same result with `precompileTemplate` and a scope hash. Everything referenced in the template has to be in `scope`, including the component:
+Projects not yet on `<template>` can use `precompileTemplate` with a scope hash, which has to include the component:
 
 ```js
-import { render, rerender } from '@ember/test-helpers';
-import { precompileTemplate } from '@ember/template-compilation';
-import { tracked } from '@glimmer/tracking';
-import MyComponent from 'my-app/components/my-component';
-
-test('it renders the name', async function (assert) {
-  class State {
-    @tracked name = 'Zoey';
-  }
-
-  const state = new State();
-
-  await render(
-    precompileTemplate('<MyComponent @name={{state.name}} />', {
-      scope: () => ({ state, MyComponent }),
-    })
-  );
-
-  assert.dom('[data-test-name]').hasText('Zoey');
-
-  state.name = 'Tomster';
-  await rerender();
-
-  assert.dom('[data-test-name]').hasText('Tomster');
-});
+await render(
+  precompileTemplate('<MyComponent @name={{state.name}} />', {
+    scope: () => ({ state, MyComponent }),
+  })
+);
 ```
 
 ### What to `await`
 
-There are two things to wait on, not three, and the difference between them is the only thing worth teaching here.
+`rerender()` from `@ember/test-helpers` is a re-export of `renderSettled()` from `@ember/renderer`. There is no behavioral difference, and the guides should not imply one; use whichever import is convenient. Both resolve once tracked state consumed by the template has reached the DOM, and neither waits on timers, requests, transitions, or test waiters. `settled()` waits for all of that.
 
-`rerender()` from `@ember/test-helpers` is `renderSettled()` from `@ember/renderer`. The entire implementation is:
-
-```js
-function rerender() {
-  return renderSettled();
-}
-```
-
-Use whichever import you find more convenient. `rerender` is the one most tests already import, since it comes from the same module as `render` and `click`; `renderSettled` is the one to reach for in code that has no business depending on `@ember/test-helpers`, such as a library that needs to flush rendering. There is no behavioral difference to document, and the guides should not imply one.
-
-Both resolve when auto-tracked state consumed by the template has been written to the DOM. Neither waits on timers, pending requests, route transitions, or test waiters.
-
-`settled()` waits for all of that: every registered settledness metric, rendering included.
-
-So: after changing tracked state, `await rerender()`. When the assertion depends on work beyond rendering, `await settled()`. The two compose when you want to catch an intermediate state before the slow thing finishes:
+So `await rerender()` after changing tracked state, and `await settled()` when the assertion depends on more than rendering. They compose when the intermediate state is the point:
 
 ```js
 state.isLoading = true;
@@ -174,41 +113,34 @@ await settled();
 assert.dom('[data-test-status]').hasText('Loaded');
 ```
 
-One implementation detail that surprises people: `render()` itself resolves with `settled()`, not `renderSettled()`. The initial render therefore waits for full settledness regardless of which helper you use afterward.
-
 ### Ecosystem
 
-A rule in `eslint-plugin-ember` should flag `this.get`, `this.set`, `this.getProperties`, and `this.setProperties` inside `test()` and hook callbacks. Catching these at lint time rather than at runtime is what makes the migration tractable for the codebases that have the most of them.
-
-Blueprints in `ember-source` and `ember-cli` that still emit `this.set` in generated rendering tests need updating. New apps should not be generating deprecated code on day one.
-
-A codemod can handle the mechanical case: a fixed set of `this.set` calls before `render`, with no reassignment afterward. Anything that reassigns mid-test needs a `rerender()` inserted at the right point, and anything with conditional or looped state changes needs a human. The codemod should skip what it cannot do safely rather than guess.
-
-`ember-source` and the wider addon ecosystem use these methods heavily in their own test suites and will need migration passes of their own. That is where the codemod earns its keep.
+- An `eslint-plugin-ember` rule flagging the four methods in tests, so they are caught at lint time rather than at runtime.
+- Blueprints in `ember-source` and `ember-cli` that still emit `this.set`.
+- A codemod for the mechanical case: state set before `render`, never reassigned. Tests that reassign need `rerender()` placed correctly, and the codemod should skip what it cannot do safely.
+- `ember-source` and the addon ecosystem need migration passes of their own.
 
 ## How We Teach This
 
-The [Testing Components](https://guides.emberjs.com/release/testing/testing-components/) guide is the main lift. It currently teaches `this.set` as the way to get data into a rendering test, so it needs rewriting rather than patching: local tracked state, `render` with a component or `<template>`, `rerender` after changes. RFC #785 deliberately confined the new pattern to a TypeScript-specific subsection, on the grounds that it was awkward without a way to pass arguments directly. That caveat has aged out. `<template>` is the default authoring format now, and the pattern is no longer TypeScript-specific. It should be taught as *the* way to write a rendering test.
-
-The guides should also make the `rerender` / `settled` distinction explicit, since `this.set`'s synchronous flush is exactly the crutch that hid it. The most common migration bug will be a missing `await rerender()`, and it presents as an assertion against stale DOM.
+[Testing Components](https://guides.emberjs.com/release/testing/testing-components/) teaches `this.set` as the way to get data into a rendering test, so it needs rewriting rather than patching. #785 confined the replacement to a TypeScript-specific subsection because passing arguments was awkward without `<template>`; that is no longer true, and it should now be taught as the default.
 
-`@ember/test-helpers` API docs mark all four methods deprecated, pointing at the deprecation guide.
+The guides should cover `rerender` versus `settled`, since `this.set`'s flush is what hid the distinction. A missing `await rerender()` will be the most common migration bug, and it presents as an assertion against stale DOM.
 
-The deprecation guide entry on `deprecations.emberjs.com` covers the four methods, why they are going away, the before/after pair above in both `<template>` and `precompileTemplate` form, the `rerender` requirement after reassignment, and an explicit note that `this.owner`, `this.element`, `this.pauseTest`, and `this.resumeTest` are unaffected. That last item matters because the first question anyone reading a deprecation about "the test context" will ask is whether their `this.owner.lookup` calls are next.
+API docs mark the four methods deprecated. The deprecation guide covers the before and after in both forms, and states that `this.owner`, `this.element`, `this.pauseTest`, and `this.resumeTest` are unaffected.
 
 ## Drawbacks
 
-The migration is large. These methods date to the original testing story, and mature codebases have them in the thousands. A codemod covers the simple shape but not the tests that reassign state, which are the ones worth testing in the first place.
+Mature codebases have thousands of these calls, and the codemod only covers tests that never reassign state, which are the least interesting ones.
 
-The replacement is more verbose for small tests. `this.set('value', x)` is one line; a tracked class plus an instance is four. That cost is real and it is paid in the tests where it buys the least. The honest defense is that the four lines are the same four lines you would write in application code, and that the one-line version was lying about how rendering works.
+The replacement is more verbose for small tests: one line becomes four. Those four are the same four you would write in application code, and the one-line version misrepresented how rendering works.
 
-Deprecating `get` and `getProperties` is arguably scope creep, since they are not `run()`-wrapped and cause none of the rendering problems. Leaving them would mean shipping a read half of an API whose write half is gone.
+Deprecating `get` and `getProperties` is arguably scope creep. Keeping them means shipping the read half of an API whose write half is gone.
 
 ## Alternatives
 
-Do nothing. The guides keep teaching a model nothing else in Ember uses, and every test that calls `this.set` becomes a problem for whoever lands the render-aware scheduler.
+Do nothing, and every `this.set` becomes a problem for whoever lands the render-aware scheduler.
 
-Deprecate everything on the test context except `this.owner`. This was the first shape considered on the PR and it does not survive contact with the details: `this.pauseTest` and `this.resumeTest` are load-bearing for debugging, `this.element` is a separate question, and stashing your own properties on `this` is a legitimate pattern.
+Deprecate everything except `this.owner`. Considered first on the PR: `pauseTest` and `resumeTest` are load-bearing for debugging, `this.element` is a separate question, and stashing properties on `this` is a common pattern.
 
 Deprecate only `set` and `setProperties`, the two with the rendering problem. Rejected above.
 

From ce483b3c9aa34f56d99c74f1364a4a836ff95592 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 15:12:02 -0400
Subject: [PATCH 05/11] Cleanup

---
 text/1203-deprecate-get-set-test-context.md | 70 +++++++++++++--------
 1 file changed, 44 insertions(+), 26 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index f7d3e89d02..93dd347b8f 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -20,24 +20,28 @@ Deprecate the four data-manipulation methods that `@ember/test-helpers` installs
 
 ## Motivation
 
-[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) made the case against these methods and shipped the replacements: `render` accepting a component, and `rerender`, in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from `@ember/renderer` in `ember-source` 4.5.0. It did not set an end date for the old way. This one does.
+[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) argued these methods should go and shipped the replacements, but never set an end date. This RFC sets one. `render` accepting a component, and `rerender`, landed in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from `@ember/renderer` in `ember-source` 4.5.0.
 
-The reasons from #785 still hold. `get` and `set` are not how application code is written after Octane. Storing template state on `this` forces TypeScript users to widen `TestContext` per module, and those widenings then appear to apply to every test in it. And a test context that is both harness and template backing object is hard to teach.
+The reasons from #785 still hold:
 
-One reason is newer. `set` and `setProperties` are `run()`-wrapped, so each call synchronously flushes the DOM, where an application coalesces updates into a single render pass. That flush is also what a render-aware scheduler ([RFC #957](https://github.com/emberjs/rfcs/pull/957)) cannot preserve. This deprecation is not a prerequisite for that work, since tests avoiding these methods can adopt an async scheduler today. But every remaining `this.set` is a test that will need rewriting when the scheduler lands, and a deprecation with a migration guide is a better place to do that.
+- `get` and `set` are not how application code is written after Octane.
+- Template state on `this` forces TypeScript users to widen `TestContext` per module, and those widenings then appear to apply to every test in it.
+- A test context that is both harness and template backing object is hard to teach.
+
+One reason is newer. `set` and `setProperties` are `run()`-wrapped, so each call synchronously flushes the DOM, where an application coalesces updates into a single render pass. That flush is also what a render-aware scheduler ([RFC #957](https://github.com/emberjs/rfcs/pull/957)) cannot preserve. This deprecation is not a prerequisite for that work, since tests avoiding these methods can adopt an async scheduler today, but every remaining `this.set` is a test that will need rewriting when the scheduler lands, and a migration guide is a better place to do that than a scheduler change.
 
 `get` and `getProperties` cause none of this. They are included because they exist to read back what `set` wrote.
 
 ## Transition Path
 
-`setupContext` from `@ember/test-helpers` installs `get`, `set`, `getProperties`, and `setProperties` on the context. All four are deprecated.
+All four are installed by `setupContext` from `@ember/test-helpers`, and all four are deprecated.
 
 ### What is not deprecated
 
-- `this.owner`, which is the whole point of the test context.
-- `this.element`, available in rendering tests. Whether it should exist at all is a separate conversation; this RFC does not have it.
-- `this.pauseTest()` and `this.resumeTest()`, useful precisely because you can reach for them mid-debug without editing your imports.
-- Assigning your own properties to `this`, a common pattern for sharing setup between hooks and tests.
+- `this.owner`.
+- `this.element`, in rendering tests. Whether it should exist at all is a separate question.
+- `this.pauseTest()` and `this.resumeTest()`, useful mid-debug without editing imports.
+- Properties you assign to `this` yourself, for sharing setup between hooks and tests.
 
 `render` binds the test context as the rendered template's backing object, which is what makes `{{this.name}}` resolve against it. This RFC does not change that binding, so `this.name = 'Zoey'` before `render` still renders "Zoey"; it just will not update on reassignment. Severing the binding needs its own RFC.
 
@@ -87,21 +91,38 @@ test('it renders the name', async function (assert) {
 
 The `await rerender()` is not optional. `this.set` gave you a synchronous flush; assigning to tracked state does not.
 
-Projects not yet on `<template>` can use `precompileTemplate` with a scope hash, which has to include the component:
+### After, for a single value
+
+Most rendering tests hold one value, and a backing class for one field is a lot of ceremony. [RFC #1071](https://github.com/emberjs/rfcs/blob/main/text/1071-overload-tracked-for-non-class-use.md) overloads `tracked` for use outside a class, which collapses it:
 
 ```js
-await render(
-  precompileTemplate('<MyComponent @name={{state.name}} />', {
-    scope: () => ({ state, MyComponent }),
-  })
-);
+import { render, rerender } from '@ember/test-helpers';
+import { tracked } from '@glimmer/tracking';
+import MyComponent from 'my-app/components/my-component';
+
+test('it renders the name', async function (assert) {
+  const name = tracked('Zoey');
+
+  await render(<template><MyComponent @name={{name.value}} /></template>);
+
+  assert.dom('[data-test-name]').hasText('Zoey');
+
+  name.value = 'Tomster';
+  await rerender();
+
+  assert.dom('[data-test-name]').hasText('Tomster');
+});
 ```
 
-### What to `await`
+That overload is accepted but not yet released. Until it ships, the class form is the migration target.
 
-`rerender()` from `@ember/test-helpers` is a re-export of `renderSettled()` from `@ember/renderer`. There is no behavioral difference, and the guides should not imply one; use whichever import is convenient. Both resolve once tracked state consumed by the template has reached the DOM, and neither waits on timers, requests, transitions, or test waiters. `settled()` waits for all of that.
+### `settled()` vs `renderSettled()` vs `rerender()`
 
-So `await rerender()` after changing tracked state, and `await settled()` when the assertion depends on more than rendering. They compose when the intermediate state is the point:
+- `settled()`, from `@ember/test-helpers`, waits on everything the test framework tracks: rendering, timers, requests, transitions, and test waiters.
+- `renderSettled()`, from `@ember/renderer`, waits only for tracked state consumed by the template to reach the DOM.
+- `rerender()`, from `@ember/test-helpers`, is a re-export of `renderSettled()`. No behavioral difference.
+
+Use `rerender()` after changing tracked state, `settled()` when the assertion depends on more than rendering, and both when the intermediate state is the point:
 
 ```js
 state.isLoading = true;
@@ -132,19 +153,16 @@ API docs mark the four methods deprecated. The deprecation guide covers the befo
 
 Mature codebases have thousands of these calls, and the codemod only covers tests that never reassign state, which are the least interesting ones.
 
-The replacement is more verbose for small tests: one line becomes four. Those four are the same four you would write in application code, and the one-line version misrepresented how rendering works.
+The replacement is more verbose for a small test, at least until `tracked()` for a single value ships. A backing class for one field is four lines where `this.set` was one.
 
-Deprecating `get` and `getProperties` is arguably scope creep. Keeping them means shipping the read half of an API whose write half is gone.
+Deprecating `get` and `getProperties` is arguably scope creep, since they cause no rendering problems on their own.
 
 ## Alternatives
 
-Do nothing, and every `this.set` becomes a problem for whoever lands the render-aware scheduler.
-
-Deprecate everything except `this.owner`. Considered first on the PR: `pauseTest` and `resumeTest` are load-bearing for debugging, `this.element` is a separate question, and stashing properties on `this` is a common pattern.
-
-Deprecate only `set` and `setProperties`, the two with the rendering problem. Rejected above.
-
-Remove without a deprecation period. Not proportionate to how widespread the pattern is.
+- Do nothing, and leave every `this.set` for whoever lands the render-aware scheduler.
+- Deprecate everything except `this.owner`. Considered first on the PR, but `pauseTest` and `resumeTest` are load-bearing for debugging, and stashing properties on `this` is a common pattern.
+- Deprecate only `set` and `setProperties`, the two that are `run()`-wrapped. Rejected above.
+- Remove without a deprecation period. Not proportionate to how widespread the pattern is.
 
 ## Unresolved questions
 

From a6e66fda8bcde2c32df4ca831461f0e5ccad10fb Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 15:53:42 -0400
Subject: [PATCH 06/11] Simplify

---
 text/1203-deprecate-get-set-test-context.md | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index 93dd347b8f..f66e2ec350 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -68,15 +68,13 @@ test('it renders the name', async function (assert) {
 
 ```js
 import { render, rerender } from '@ember/test-helpers';
-import { tracked } from '@glimmer/tracking';
+import { trackedObject } from '@ember/reactive/collections';
 import MyComponent from 'my-app/components/my-component';
 
 test('it renders the name', async function (assert) {
-  class State {
-    @tracked name = 'Zoey';
-  }
-
-  const state = new State();
+  const state = trackedObject({
+    name: 'Zoey',
+  });
 
   await render(<template><MyComponent @name={{state.name}} /></template>);
 
@@ -89,11 +87,9 @@ test('it renders the name', async function (assert) {
 });
 ```
 
-The `await rerender()` is not optional. `this.set` gave you a synchronous flush; assigning to tracked state does not.
-
 ### After, for a single value
 
-Most rendering tests hold one value, and a backing class for one field is a lot of ceremony. [RFC #1071](https://github.com/emberjs/rfcs/blob/main/text/1071-overload-tracked-for-non-class-use.md) overloads `tracked` for use outside a class, which collapses it:
+Many rendering tests hold one value:
 
 ```js
 import { render, rerender } from '@ember/test-helpers';
@@ -114,8 +110,6 @@ test('it renders the name', async function (assert) {
 });
 ```
 
-That overload is accepted but not yet released. Until it ships, the class form is the migration target.
-
 ### `settled()` vs `renderSettled()` vs `rerender()`
 
 - `settled()`, from `@ember/test-helpers`, waits on everything the test framework tracks: rendering, timers, requests, transitions, and test waiters.

From ca07b3ec05edbdeddec39331f3bbaa8ec7021a8e Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Fri, 14 Aug 2026 15:54:41 -0400
Subject: [PATCH 07/11] Reduce

---
 text/1203-deprecate-get-set-test-context.md | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index f66e2ec350..da40778ead 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -36,15 +36,6 @@ One reason is newer. `set` and `setProperties` are `run()`-wrapped, so each call
 
 All four are installed by `setupContext` from `@ember/test-helpers`, and all four are deprecated.
 
-### What is not deprecated
-
-- `this.owner`.
-- `this.element`, in rendering tests. Whether it should exist at all is a separate question.
-- `this.pauseTest()` and `this.resumeTest()`, useful mid-debug without editing imports.
-- Properties you assign to `this` yourself, for sharing setup between hooks and tests.
-
-`render` binds the test context as the rendered template's backing object, which is what makes `{{this.name}}` resolve against it. This RFC does not change that binding, so `this.name = 'Zoey'` before `render` still renders "Zoey"; it just will not update on reassignment. Severing the binding needs its own RFC.
-
 ### Before
 
 ```js

From e23efdc9f98b643f1b8ee39761b0881ceffd3a5a Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 19 Aug 2026 15:01:22 -0400
Subject: [PATCH 08/11] Update text/1203-deprecate-get-set-test-context.md

Co-authored-by: Katie Gengler <katie@kmg.io>
---
 text/1203-deprecate-get-set-test-context.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index da40778ead..33bb0bd687 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -20,7 +20,7 @@ Deprecate the four data-manipulation methods that `@ember/test-helpers` installs
 
 ## Motivation
 
-[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) argued these methods should go and shipped the replacements, but never set an end date. This RFC sets one. `render` accepting a component, and `rerender`, landed in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from `@ember/renderer` in `ember-source` 4.5.0.
+[RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) shipped replacements for these methods. We believe that rendering tests should be using the replacements: `render` accepting a component, and `rerender`, landed in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from `@ember/renderer` in `ember-source` 4.5.0.
 
 The reasons from #785 still hold:
 

From 74e3f85434a3eaa45fd9e191b61914a71de8deeb Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 19 Aug 2026 15:01:41 -0400
Subject: [PATCH 09/11] Update text/1203-deprecate-get-set-test-context.md

Co-authored-by: Katie Gengler <katie@kmg.io>
---
 text/1203-deprecate-get-set-test-context.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index 33bb0bd687..2cd03cca7b 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -34,7 +34,6 @@ One reason is newer. `set` and `setProperties` are `run()`-wrapped, so each call
 
 ## Transition Path
 
-All four are installed by `setupContext` from `@ember/test-helpers`, and all four are deprecated.
 
 ### Before
 

From d935a4177a1436627f1be992ebcfa58458ed0c38 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 19 Aug 2026 15:02:49 -0400
Subject: [PATCH 10/11] Delete background from #785

---
 text/1203-deprecate-get-set-test-context.md | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index 2cd03cca7b..5eb50167a8 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -22,16 +22,6 @@ Deprecate the four data-manipulation methods that `@ember/test-helpers` installs
 
 [RFC #785](https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md) shipped replacements for these methods. We believe that rendering tests should be using the replacements: `render` accepting a component, and `rerender`, landed in `@ember/test-helpers` 2.8.0, backed by `renderSettled` from `@ember/renderer` in `ember-source` 4.5.0.
 
-The reasons from #785 still hold:
-
-- `get` and `set` are not how application code is written after Octane.
-- Template state on `this` forces TypeScript users to widen `TestContext` per module, and those widenings then appear to apply to every test in it.
-- A test context that is both harness and template backing object is hard to teach.
-
-One reason is newer. `set` and `setProperties` are `run()`-wrapped, so each call synchronously flushes the DOM, where an application coalesces updates into a single render pass. That flush is also what a render-aware scheduler ([RFC #957](https://github.com/emberjs/rfcs/pull/957)) cannot preserve. This deprecation is not a prerequisite for that work, since tests avoiding these methods can adopt an async scheduler today, but every remaining `this.set` is a test that will need rewriting when the scheduler lands, and a migration guide is a better place to do that than a scheduler change.
-
-`get` and `getProperties` cause none of this. They are included because they exist to read back what `set` wrote.
-
 ## Transition Path
 
 

From 5a81e28cca94f4611a79d9c30a641c8ee9de2212 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 19 Aug 2026 15:03:49 -0400
Subject: [PATCH 11/11] Delete more

---
 text/1203-deprecate-get-set-test-context.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/text/1203-deprecate-get-set-test-context.md b/text/1203-deprecate-get-set-test-context.md
index 5eb50167a8..5ddbe922c9 100644
--- a/text/1203-deprecate-get-set-test-context.md
+++ b/text/1203-deprecate-get-set-test-context.md
@@ -117,8 +117,6 @@ assert.dom('[data-test-status]').hasText('Loaded');
 
 ## How We Teach This
 
-[Testing Components](https://guides.emberjs.com/release/testing/testing-components/) teaches `this.set` as the way to get data into a rendering test, so it needs rewriting rather than patching. #785 confined the replacement to a TypeScript-specific subsection because passing arguments was awkward without `<template>`; that is no longer true, and it should now be taught as the default.
-
 The guides should cover `rerender` versus `settled`, since `this.set`'s flush is what hid the distinction. A missing `await rerender()` will be the most common migration bug, and it presents as an assertion against stale DOM.
 
 API docs mark the four methods deprecated. The deprecation guide covers the before and after in both forms, and states that `this.owner`, `this.element`, `this.pauseTest`, and `this.resumeTest` are unaffected.