From 9c07150b68c11111a3da44dd1926e4ddeca43751 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Wed, 1 Dec 2021 11:57:29 -0700
Subject: [PATCH 01/13] first pass

---
 text/0000-remove-set-get-in-tests.md | 141 +++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 text/0000-remove-set-get-in-tests.md

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
new file mode 100644
index 0000000000..7120864067
--- /dev/null
+++ b/text/0000-remove-set-get-in-tests.md
@@ -0,0 +1,141 @@
+---
+Stage: Accepted
+Start Date: 2021-11-30
+Release Date: Unreleased
+Release Versions:
+  ember-source: vX.Y.Z
+  ember-data: vX.Y.Z
+Relevant Team(s): Ember
+RFC PR:
+---
+
+<!---
+Directions for above:
+
+Stage: Leave as is
+Start Date: Fill in with today's date, YYYY-MM-DD
+Release Date: Leave as is
+Release Versions: Leave as is
+Relevant Team(s): Fill this in with the [team(s)](README.md#relevant-teams) to which this RFC applies
+RFC PR: Fill this in with the URL for the Proposal RFC PR
+-->
+
+# <RFC title>
+
+## Summary
+
+Introduce new testing utilities that remove the need for the use of `get`/`set` on `this` in test contexts. This will make rendering tests behave more like application code, and also greatly simplify the process of writing rendering tests in TypeScript since it will remove the need to append type information to `this` as properties are set.
+
+## Motivation
+
+Current rendering tests require developers to set values on `this` in order for them to actually be present in the template that gets rendered as part of the test. For example, if we're testing that a component correctly displays a value that gets passed in as an argument, we'd do something like:
+
+```js
+this.set('name', 'foo');
+
+await render(hbs`<MyComponent @name={{this.name}} />`);
+
+assert.dom('[data-test-name]').hasText(this.get('name'));
+```
+
+This approach has two main issues:
+
+1. It's not consistent with any other programming model in Ember
+1. It makes writing tests in TypeScript a huge pain
+
+On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Furthermore, `this.set` inside of a test is even stranger than it was in application code since `set` in tests also manipulates the run loop and flushes the entirety of DOM (in additon to actually setting the value of a property on `this`), and the value of `this` is extremely murky in the first place. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
+
+On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), since rendering tests require developers to arbitrarily add (and change) properties on `this`, you have to define (and re-define) the interface for `this` to accomodate all of those properties just to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type.
+
+The goal of this RFC, then, is to greatly simplify the testing model by removing the need for `get` and `set` in rendering tests, thereby reducing the reliance on `this`.
+
+## Detailed design
+
+We will introduce several new/refactored utilities for use in rendering tests:
+
+1. A new version of `render` that accepts a component rather than a template.
+1. A new `scopedTemplate` function that accepts a template and returns a component _and is lexically scoped_
+1. A new `rerender` function that would be used after the initial `render` call
+
+Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test file. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
+
+Once we've got this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template (created using the `hbs` macro today, or the `<template>` tag in the future), and return a newly-formed component class which could then be passed to our new version of `render`. In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that it's values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+
+```js
+import { render } from '@ember/test-helpers';
+import { scopedTemplate } from 'ember-cli-htmlbars';
+
+// setup elided
+test('it works', async function (assert) {
+  const somePerson = {
+    name: 'Zoey',
+    age: 5,
+  };
+
+  const component = scopedTemplate(hbs`
+    <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
+  `);
+
+  await render(component);
+
+  assert.dom(this.element).hasText(somePerson.name);
+});
+```
+
+Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd update the values using `this.set` and then wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`). Instead, we propose a new `rerender` function that exclusively waits on pending render operations, but ignores all other [settledness metrics](https://github.com/emberjs/ember-test-helpers/blob/master/API.md#issettled). When combined with [tracked state](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/#toc_autotracking-basics), this new `rerender` function allows developers to make updates to their component state and `await` the newly rendered version of their component _without_ having to also wait for other pending timers or run loops. In other words, they can still assert against changes in the DOM, but would also be able to assert against things like loading states without having to use `waitFor` since `rerender` would not wait for things like async operations to complete.
+
+Continuing the example from above, here's what we'd expect an update and re-render to look like:
+
+```js
+import { render, rerender } from '@ember/test-helpers';
+import { scopedTemplate } from 'ember-cli-htmlbars';
+import { tracked } from 'tracked-built-ins';
+
+// setup elided
+test('it works', async function (assert) {
+  const somePerson = tracked({
+    name: 'Zoey',
+    age: 5,
+  });
+
+  const component = scopedTemplate(hbs`
+    <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
+  `);
+
+  await render(component);
+
+  assert.dom(this.element).hasText(somePerson.name);
+
+  somePerson.name = 'Zoeyyyyyyyyyyyyy';
+
+  await rerender();
+
+  assert.dom(this.element).hasText(somePerson.name);
+});
+```
+
+It's worth noting that rendering tests without `get`/`set` are actually possible today using a combination of the `precompileTemplate` function from `@ember/template-compilation`, a scope object containing all of the relevant values referenced in the template, and the `settled` function from `@ember/test-helpers`. Ultimately this RFC would largely end up exposing these existing APIs in a way that is both more user-friendly and better-suited to both [First-Class Component Templates](https://github.com/emberjs/rfcs/pull/779) and [TypeScript](https://github.com/emberjs/rfcs/pull/724)
+
+## How we teach this
+
+We'd need to update the [testing components](https://guides.emberjs.com/release/testing/testing-components/) section of the official guides to document this new approach.
+
+We'd also need to update the [API docs for ember-test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` function..
+
+Finally, we'd need to document the `scopedTemplate` function **in whatever package it ends up living in????????????**.
+
+All things considered, the changes in this RFC should result in a component testing model that ultimately _more_ intuitive. We could also introduce a configuration option to `ember-test-helpers` that would allow users to turn on assertion that prevents rendering tests from being written using the old method to help codebases migrate.
+
+## Drawbacks
+
+Ember's testing setup is one its most valuable features, and this RFC would introduce changes to a testing model that ultimately already works fine. These changes would be introduced alongside the existing rendering test models, so they would not constitute a breaking change, but would introduce additional overhead in terms of "old vs. new", similar to the overhead of Octane, or the Grand Testing Unification RFCs.
+
+## Alternatives
+
+- Leave things as they are.
+- Encourage people to use `precompileTemplate` along with the current version of `render`.
+
+## Unresolved questions
+
+> Optional, but suggested for first drafts. What parts of the design are still
+> TBD?

From 9280bb003a8d403e4f9d706c075ae13d12d8b3ac Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Tue, 7 Dec 2021 10:41:44 -0700
Subject: [PATCH 02/13] Apply suggestions from code review

Co-authored-by: Chris Krycho <hello@chriskrycho.com>
---
 text/0000-remove-set-get-in-tests.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index 7120864067..faa50fe998 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -45,7 +45,7 @@ This approach has two main issues:
 
 On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Furthermore, `this.set` inside of a test is even stranger than it was in application code since `set` in tests also manipulates the run loop and flushes the entirety of DOM (in additon to actually setting the value of a property on `this`), and the value of `this` is extremely murky in the first place. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
 
-On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), since rendering tests require developers to arbitrarily add (and change) properties on `this`, you have to define (and re-define) the interface for `this` to accomodate all of those properties just to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type.
+On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate *all* of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write actually safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually *are* available.
 
 The goal of this RFC, then, is to greatly simplify the testing model by removing the need for `get` and `set` in rendering tests, thereby reducing the reliance on `this`.
 
@@ -59,7 +59,7 @@ We will introduce several new/refactored utilities for use in rendering tests:
 
 Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test file. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
 
-Once we've got this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template (created using the `hbs` macro today, or the `<template>` tag in the future), and return a newly-formed component class which could then be passed to our new version of `render`. In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that it's values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a newly-formed component class which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) would supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping *without* requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that it's values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
 
 ```js
 import { render } from '@ember/test-helpers';
@@ -82,7 +82,9 @@ test('it works', async function (assert) {
 });
 ```
 
-Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd update the values using `this.set` and then wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`). Instead, we propose a new `rerender` function that exclusively waits on pending render operations, but ignores all other [settledness metrics](https://github.com/emberjs/ember-test-helpers/blob/master/API.md#issettled). When combined with [tracked state](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/#toc_autotracking-basics), this new `rerender` function allows developers to make updates to their component state and `await` the newly rendered version of their component _without_ having to also wait for other pending timers or run loops. In other words, they can still assert against changes in the DOM, but would also be able to assert against things like loading states without having to use `waitFor` since `rerender` would not wait for things like async operations to complete.
+Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd *usually* just update the values using `this.set`, which immediately triggers a rerender. In more complex cases, e.g. where there is some async operation involved, we would wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`).
+
+Instead, we propose a new `rerender` function that exclusively waits on pending render operations, but ignores all other [settledness metrics](https://github.com/emberjs/ember-test-helpers/blob/master/API.md#issettled). When combined with [tracked state](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/#toc_autotracking-basics), this new `rerender` function allows developers to make updates to their component state and `await` the newly rendered version of their component _without_ having to also wait for other pending timers or run loops. In other words, they can still assert against changes in the DOM, but would also be able to assert against things like loading states without having to use `waitFor` since `rerender` would not wait for things like async operations to complete.
 
 Continuing the example from above, here's what we'd expect an update and re-render to look like:
 

From a19eade7a529c697224ab17d02d9831379fd540f Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Tue, 7 Dec 2021 12:32:26 -0700
Subject: [PATCH 03/13] more feedback

---
 text/0000-remove-set-get-in-tests.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index faa50fe998..4b1e1574a1 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -45,7 +45,7 @@ This approach has two main issues:
 
 On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Furthermore, `this.set` inside of a test is even stranger than it was in application code since `set` in tests also manipulates the run loop and flushes the entirety of DOM (in additon to actually setting the value of a property on `this`), and the value of `this` is extremely murky in the first place. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
 
-On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate *all* of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write actually safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually *are* available.
+On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate _all_ of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write actually safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually _are_ available.
 
 The goal of this RFC, then, is to greatly simplify the testing model by removing the need for `get` and `set` in rendering tests, thereby reducing the reliance on `this`.
 
@@ -59,7 +59,7 @@ We will introduce several new/refactored utilities for use in rendering tests:
 
 Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test file. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
 
-Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a newly-formed component class which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) would supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping *without* requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that it's values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a newly-formed component class which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) would supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
 
 ```js
 import { render } from '@ember/test-helpers';
@@ -82,7 +82,7 @@ test('it works', async function (assert) {
 });
 ```
 
-Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd *usually* just update the values using `this.set`, which immediately triggers a rerender. In more complex cases, e.g. where there is some async operation involved, we would wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`).
+Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd _usually_ just update the values using `this.set`, which immediately triggers a rerender. In more complex cases, e.g. where there is some async operation involved, we would wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`).
 
 Instead, we propose a new `rerender` function that exclusively waits on pending render operations, but ignores all other [settledness metrics](https://github.com/emberjs/ember-test-helpers/blob/master/API.md#issettled). When combined with [tracked state](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/#toc_autotracking-basics), this new `rerender` function allows developers to make updates to their component state and `await` the newly rendered version of their component _without_ having to also wait for other pending timers or run loops. In other words, they can still assert against changes in the DOM, but would also be able to assert against things like loading states without having to use `waitFor` since `rerender` would not wait for things like async operations to complete.
 
@@ -116,26 +116,26 @@ test('it works', async function (assert) {
 });
 ```
 
-It's worth noting that rendering tests without `get`/`set` are actually possible today using a combination of the `precompileTemplate` function from `@ember/template-compilation`, a scope object containing all of the relevant values referenced in the template, and the `settled` function from `@ember/test-helpers`. Ultimately this RFC would largely end up exposing these existing APIs in a way that is both more user-friendly and better-suited to both [First-Class Component Templates](https://github.com/emberjs/rfcs/pull/779) and [TypeScript](https://github.com/emberjs/rfcs/pull/724)
+It's worth noting that rendering tests without `get`/`set` are actually possible today using a combination of the `precompileTemplate` function from `@ember/template-compilation`, a scope object containing all of the relevant values referenced in the template, and the `settled` function from `@ember/test-helpers`. Accordingly, the implementation of this RFC would largely involve exposing these existing APIs in a way that is both more user-friendly and better-suited to both [First-Class Component Templates](https://github.com/emberjs/rfcs/pull/779) and [TypeScript](https://github.com/emberjs/rfcs/pull/724), rather than introducing a significant amount of new internal functionality.
 
 ## How we teach this
 
 We'd need to update the [testing components](https://guides.emberjs.com/release/testing/testing-components/) section of the official guides to document this new approach.
 
-We'd also need to update the [API docs for ember-test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` function..
+We'd also need to update the [API docs for ember-test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` and `scopedTemplate` functions.
 
-Finally, we'd need to document the `scopedTemplate` function **in whatever package it ends up living in????????????**.
-
-All things considered, the changes in this RFC should result in a component testing model that ultimately _more_ intuitive. We could also introduce a configuration option to `ember-test-helpers` that would allow users to turn on assertion that prevents rendering tests from being written using the old method to help codebases migrate.
+All things considered, the changes in this RFC should result in a component testing model that is ultimately _more_ intuitive. We could also introduce a configuration option to `@ember/test-helpers` that would allow users to turn on assertion that prevents rendering tests from being written using the old method to help codebases migrate.
 
 ## Drawbacks
 
-Ember's testing setup is one its most valuable features, and this RFC would introduce changes to a testing model that ultimately already works fine. These changes would be introduced alongside the existing rendering test models, so they would not constitute a breaking change, but would introduce additional overhead in terms of "old vs. new", similar to the overhead of Octane, or the Grand Testing Unification RFCs.
+Ember's testing setup is one its most valuable features, and this RFC would introduce changes to a testing model that already works fine. These changes would be introduced alongside the existing rendering test models, so they would not constitute a breaking change, but would introduce additional overhead in terms of "old vs. new", similar to the overhead of Octane, or the Grand Testing Unification RFCs.
 
 ## Alternatives
 
 - Leave things as they are.
 - Encourage people to use `precompileTemplate` along with the current version of `render`.
+- Only implement the changes to `render` and wait for first-class component templates rather than introducing `scopedTemplate`
+  - That said, the upside to implementing `scopedTemplate` along with the changes to `render` is that it would use the same primitives as first-class component templates, which allows tests written using `scopedTemplate` to be codemodded easily and safely, and allows us to moving the state of rendering tests forward without having to wait on the much larger first-class component template implementation. In addition, implementing `scopedTemplate` sooner provides a lot of value to TypeScript users immediately.
 
 ## Unresolved questions
 

From ac6328613af395c97c408482ded29db034847034 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Tue, 7 Dec 2021 13:33:03 -0700
Subject: [PATCH 04/13] more tweaks

---
 text/0000-remove-set-get-in-tests.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index 4b1e1574a1..fd70abb02c 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -59,7 +59,7 @@ We will introduce several new/refactored utilities for use in rendering tests:
 
 Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test file. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
 
-Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a newly-formed component class which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) would supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a template-only component which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) would supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
 
 ```js
 import { render } from '@ember/test-helpers';

From 5ade954d482186c28a9342bcfac8c6778fc490b5 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Wed, 8 Dec 2021 12:44:40 -0700
Subject: [PATCH 05/13] Apply suggestions from code review

Co-authored-by: Robert Jackson <me@rwjblue.com>
---
 text/0000-remove-set-get-in-tests.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index fd70abb02c..aac6ea1939 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -24,7 +24,7 @@ RFC PR: Fill this in with the URL for the Proposal RFC PR
 
 ## Summary
 
-Introduce new testing utilities that remove the need for the use of `get`/`set` on `this` in test contexts. This will make rendering tests behave more like application code, and also greatly simplify the process of writing rendering tests in TypeScript since it will remove the need to append type information to `this` as properties are set.
+Introduce new testing utilities that remove the need for the use of `this.get`/`this.set` in test contexts. This will make rendering tests behave more like application code, and also greatly simplify the process of writing rendering tests in TypeScript since it will remove the need to append type information to `this` as properties are set.
 
 ## Motivation
 
@@ -45,7 +45,7 @@ This approach has two main issues:
 
 On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Furthermore, `this.set` inside of a test is even stranger than it was in application code since `set` in tests also manipulates the run loop and flushes the entirety of DOM (in additon to actually setting the value of a property on `this`), and the value of `this` is extremely murky in the first place. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
 
-On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate _all_ of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write actually safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually _are_ available.
+On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate _all_ of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually _are_ available.
 
 The goal of this RFC, then, is to greatly simplify the testing model by removing the need for `get` and `set` in rendering tests, thereby reducing the reliance on `this`.
 
@@ -53,13 +53,13 @@ The goal of this RFC, then, is to greatly simplify the testing model by removing
 
 We will introduce several new/refactored utilities for use in rendering tests:
 
-1. A new version of `render` that accepts a component rather than a template.
-1. A new `scopedTemplate` function that accepts a template and returns a component _and is lexically scoped_
-1. A new `rerender` function that would be used after the initial `render` call
+1. Update the `render` helper to accept either a component or a template snippet.
+1. A new `scopedTemplate` function that accepts a template and returns a component _that uses lexically scoped data_
+1. A new `rerender` function that would be used after the initial `render` call to wait for DOM updates
 
-Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test file. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
+Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
 
-Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a template-only component which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) would supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would be lexically scoped, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a template-only component which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) could supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would have access to lexically scoped data, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
 
 ```js
 import { render } from '@ember/test-helpers';

From fa59e46859644431004598aca3568ef754891569 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Wed, 8 Dec 2021 14:19:46 -0700
Subject: [PATCH 06/13] updates

---
 text/0000-remove-set-get-in-tests.md | 29 +++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index aac6ea1939..0993d29774 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -35,17 +35,24 @@ this.set('name', 'foo');
 
 await render(hbs`<MyComponent @name={{this.name}} />`);
 
+assert.dom('[data-test-name]').hasText(this.get('name'));
+
+this.set('name', 'FOO');
+
 assert.dom('[data-test-name]').hasText(this.get('name'));
 ```
 
-This approach has two main issues:
+This approach has three main issues:
 
 1. It's not consistent with any other programming model in Ember
+1. It synchronously flushes the DOM
 1. It makes writing tests in TypeScript a huge pain
 
-On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Furthermore, `this.set` inside of a test is even stranger than it was in application code since `set` in tests also manipulates the run loop and flushes the entirety of DOM (in additon to actually setting the value of a property on `this`), and the value of `this` is extremely murky in the first place. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
+On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Additonally, the value of `this` inside of a test is extremely murky. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
+
+On the second point: `this.set` is actually [run-wrapped when called in tests](https://github.com/emberjs/ember-test-helpers/blob/master/addon-test-support/@ember/test-helpers/setup-context.ts#L412-L423), which means that every time someone calls `this.set`, they are actually synchronously flushing the entirety of the DOM and triggering a re-render of the entire test template. This _in no way_ resembles the relationship between data updates and re-renders in application code. In application code, changes to the underlying data in template are coalesced into a single DOM update, which, in turn, re-renders only the parts of the DOM that are affected by the changed data. As a result, rendering tests end up essentially testing a version of rendering that isn't even used in the application being tested.
 
-On the second point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate _all_ of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually _are_ available.
+On the third point: having to set properties on `this` leads to a whole bunch of papercuts when writing tests in TypeScript. [As discussed in the `ember-cli-typescript` docs](https://docs.ember-cli-typescript.com/ember/testing#the-testcontext), rendering tests require developers to arbitrarily add (and change) properties on `this`. Developers thus have to define (and re-define) the interface for `this` to accommodate _all_ of those properties to prevent TypeScript from complaining that each of the values that were set don't exist on the `TestContext` type. Beyond simply being annoying, this actually makes it impossible to write safe and useful types spanning multiple tests: properties declared for one test appear to be available in all of the tests in a module (and get autocompleted accordingly), whether or not they actually _are_ available.
 
 The goal of this RFC, then, is to greatly simplify the testing model by removing the need for `get` and `set` in rendering tests, thereby reducing the reliance on `this`.
 
@@ -59,7 +66,7 @@ We will introduce several new/refactored utilities for use in rendering tests:
 
 Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
 
-Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a template created using the `hbs` macro, and return a template-only component which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) could supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would have access to lexically scoped data, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a string and return a template-only component which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) could supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would have access to lexically scoped data, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
 
 ```js
 import { render } from '@ember/test-helpers';
@@ -72,7 +79,7 @@ test('it works', async function (assert) {
     age: 5,
   };
 
-  const component = scopedTemplate(hbs`
+  const component = scopedTemplate(`
     <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
   `);
 
@@ -91,16 +98,16 @@ Continuing the example from above, here's what we'd expect an update and re-rend
 ```js
 import { render, rerender } from '@ember/test-helpers';
 import { scopedTemplate } from 'ember-cli-htmlbars';
-import { tracked } from 'tracked-built-ins';
+import { tracked } from '@glimmer/tracking';
 
 // setup elided
 test('it works', async function (assert) {
-  const somePerson = tracked({
-    name: 'Zoey',
-    age: 5,
-  });
+  const somePerson = new class {
+    @tracked name = 'Zoey',
+    @tracked age = 5,
+  };
 
-  const component = scopedTemplate(hbs`
+  const component = scopedTemplate(`
     <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
   `);
 

From 3c3047df88ef28ac92550e7336d7490bb49e5a93 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Fri, 10 Dec 2021 10:41:54 -0700
Subject: [PATCH 07/13] another pass on the design

---
 text/0000-remove-set-get-in-tests.md | 54 +++++++++++++++++++++++-----
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index 0993d29774..e903dbd33c 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -64,13 +64,31 @@ We will introduce several new/refactored utilities for use in rendering tests:
 1. A new `scopedTemplate` function that accepts a template and returns a component _that uses lexically scoped data_
 1. A new `rerender` function that would be used after the initial `render` call to wait for DOM updates
 
-Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that accepts a fully-formed component instead, since components have their own context and are self-contained.
+### Updated `render` helper
 
-Once we have this new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a string and return a template-only component which could then be passed to our new version of `render`. (A proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) could supersede this, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.) In addition, the template passed to `scopedTemplate` would have access to lexically scoped data, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
+Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that can alternatively accept a fully-formed component, since components have their own context and are self-contained.
+
+The updated version of `render` would be imported from `@ember/test-helpers` and have the following signature:
+
+```ts
+function render(template: TemplateFactory | Component, options?: RenderOptions): Promise<void>;
+```
+
+### `scopedTemplate`
+
+Now that we have a new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a [strict-mode](https://github.com/emberjs/rfcs/blob/master/text/0496-handlebars-strict-mode.md) template and return a renderable component which could then be passed to our updated version of `render`:
+
+```ts
+function scopedTemplate(templateString: string): Component;
+```
+
+Much like `hbs`, `scopedTemplate` would be a Babel macro, meaning it could be invoked like a function (e.g. `scopedTemplate('<Foo />')`) or like a tagged template string (e.g. `` scopedTemplate`<Foo />` ``), and it does _not_ accept any kind of string interpolation or concatentation (i.e.`` scopedTemplate`<Foo @name=${'blah'} />` `` is not allowed).
+
+In addition, the template passed to `scopedTemplate` would have access to lexically scoped data, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
 
 ```js
 import { render } from '@ember/test-helpers';
-import { scopedTemplate } from 'ember-cli-htmlbars';
+import { scopedTemplate } from '@ember/template-compilation';
 
 // setup elided
 test('it works', async function (assert) {
@@ -79,9 +97,9 @@ test('it works', async function (assert) {
     age: 5,
   };
 
-  const component = scopedTemplate(`
+  const component = scopedTemplate`
     <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
-  `);
+  `;
 
   await render(component);
 
@@ -89,15 +107,29 @@ test('it works', async function (assert) {
 });
 ```
 
+In the (near?) future, a proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) could supersede `scopedTemplate`, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.
+
+Since `scopedTemplate` would require a strict-mode template, it would be supported back to v3.25. (If we had to also support loose mode, it'd only work starting in 3.28).
+
+### `rerender`
+
 Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd _usually_ just update the values using `this.set`, which immediately triggers a rerender. In more complex cases, e.g. where there is some async operation involved, we would wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`).
 
-Instead, we propose a new `rerender` function that exclusively waits on pending render operations, but ignores all other [settledness metrics](https://github.com/emberjs/ember-test-helpers/blob/master/API.md#issettled). When combined with [tracked state](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/#toc_autotracking-basics), this new `rerender` function allows developers to make updates to their component state and `await` the newly rendered version of their component _without_ having to also wait for other pending timers or run loops. In other words, they can still assert against changes in the DOM, but would also be able to assert against things like loading states without having to use `waitFor` since `rerender` would not wait for things like async operations to complete.
+Instead, we propose adding a new `rerender` function to `@ember/test-helpers` that exclusively waits on pending render operations, but ignores all other [settledness metrics](https://github.com/emberjs/ember-test-helpers/blob/master/API.md#issettled):
+
+```ts
+rerender(): Promise<void>
+```
+
+In order to implement `rerender`, we would also expose the work done by @rwjblue on [`renderSettled`](https://github.com/emberjs/ember.js/blob/703b9ca2653a6b479a762b30dca1a33eaa13d8ab/packages/%40ember/-internals/glimmer/lib/renderer.ts#L219-L240) as public API in a new `@ember/renderer` module so that it could then be imported and used by `@ember/test-helpers` without issuue.
+
+When combined with [tracked state](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/#toc_autotracking-basics), this new `rerender` function allows developers to make updates to their component state and `await` the newly rendered version of their component _without_ having to also wait for other pending timers or run loops. In other words, they can still assert against changes in the DOM, but would also be able to assert against things like loading states without having to use `waitFor` since `rerender` would not wait for things like async operations to complete.
 
 Continuing the example from above, here's what we'd expect an update and re-render to look like:
 
 ```js
 import { render, rerender } from '@ember/test-helpers';
-import { scopedTemplate } from 'ember-cli-htmlbars';
+import { scopedTemplate } from '@ember/template-compilation';
 import { tracked } from '@glimmer/tracking';
 
 // setup elided
@@ -107,9 +139,9 @@ test('it works', async function (assert) {
     @tracked age = 5,
   };
 
-  const component = scopedTemplate(`
+  const component = scopedTemplate`
     <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
-  `);
+  `;
 
   await render(component);
 
@@ -146,5 +178,9 @@ Ember's testing setup is one its most valuable features, and this RFC would intr
 
 ## Unresolved questions
 
+- Should we also support loose-mode templates for `scopedTemplate` in some way?
+  - This has the benefit of being more flexible and slightly better-suited to today's Ember template.
+  - On the other hand, the future of Ember templates is exclusively strict mode, and this RFC is really aimed at 4.0 and beyond, so support loose-mode may end up be an added cost without much additional value.
+
 > Optional, but suggested for first drafts. What parts of the design are still
 > TBD?

From 2cf58a6e4367f8c2ff8ad9fd2130fdba6b15bb0f Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Tue, 14 Dec 2021 11:45:41 -0700
Subject: [PATCH 08/13] add API docs

---
 text/0000-remove-set-get-in-tests.md | 51 ++++++++++++++++++++++++++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index e903dbd33c..3b43035697 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -48,7 +48,7 @@ This approach has three main issues:
 1. It synchronously flushes the DOM
 1. It makes writing tests in TypeScript a huge pain
 
-On the first point: `this.set` is essentially irrelevant everwhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Additonally, the value of `this` inside of a test is extremely murky. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
+On the first point: `this.set` is essentially irrelevant everywhere else in Ember. In a post-Octane world, we no longer need to `get` or `set`, and it is, in fact, frequently discouraged as an unnecessary complication. Additonally, the value of `this` inside of a test is extremely murky. The fact that `this` is both the test context _and_ a sort of ersatz scope for the surrounding "template" of the rendering test is not exactly intuitive or easy to teach.
 
 On the second point: `this.set` is actually [run-wrapped when called in tests](https://github.com/emberjs/ember-test-helpers/blob/master/addon-test-support/@ember/test-helpers/setup-context.ts#L412-L423), which means that every time someone calls `this.set`, they are actually synchronously flushing the entirety of the DOM and triggering a re-render of the entire test template. This _in no way_ resembles the relationship between data updates and re-renders in application code. In application code, changes to the underlying data in template are coalesced into a single DOM update, which, in turn, re-renders only the parts of the DOM that are affected by the changed data. As a result, rendering tests end up essentially testing a version of rendering that isn't even used in the application being tested.
 
@@ -161,7 +161,54 @@ It's worth noting that rendering tests without `get`/`set` are actually possible
 
 We'd need to update the [testing components](https://guides.emberjs.com/release/testing/testing-components/) section of the official guides to document this new approach.
 
-We'd also need to update the [API docs for ember-test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` and `scopedTemplate` functions.
+We'd also need to update the [API docs for @ember/test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` function.
+
+Finally, we'd need to document the new `scopedTemplate` function in `@ember/template-compilation`.
+
+API documentation for the three new functions are included below:
+
+### render
+
+```ts
+/**
+  Renders the provided template or component and appends it to the DOM, overwriting any previously-rendered template or component.
+  @public
+  @param {CompiledTemplate|Component} template the template or component to render
+  @param {RenderOptions} options options hash containing engine owner ({ owner: engineOwner })
+  @returns {Promise<void>} resolves when settled
+*/
+render(template: CompiledTemplate | Component, options?: RenderOptions): Promise<void>;
+```
+
+### rerender
+
+```ts
+/**
+  Returns a promise that resolves when rendering has settled.  Settled in this context is defined as when all of the
+  tags in use are "current". When this is checked at the _end_ of the run loop, this essentially guarantees that all
+  rendering is completed.
+  @public
+  @returns {Promise<void>} resolves when settled
+*/
+rerender(): Promise<void>
+```
+
+### scopedTemplate
+
+```ts
+/**
+ Turns a lexically scoped strict-mode template into a Component. The string passed to `scopedTemplate` may not contain
+ any interpolated values or other dynamic elements, but it may refer to other values/variables in the surrounding scope.
+ @public
+ @param {string} templateString a string containing a strict-mode template
+ @returns {Component} a component that can be passed to `render`
+ @example
+     let person = { name: 'Chris' };
+     scopedTemplate('<Foo @name={{person.name}} />`)
+ **/
+
+function scopedTemplate(templateString: string): Component;
+```
 
 All things considered, the changes in this RFC should result in a component testing model that is ultimately _more_ intuitive. We could also introduce a configuration option to `@ember/test-helpers` that would allow users to turn on assertion that prevents rendering tests from being written using the old method to help codebases migrate.
 

From 85f732b976c19c5cebdebada214b6c5c8af564cc Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Mon, 3 Jan 2022 13:04:34 -0700
Subject: [PATCH 09/13] add title

---
 text/0000-remove-set-get-in-tests.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0000-remove-set-get-in-tests.md
index 3b43035697..d65e187304 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0000-remove-set-get-in-tests.md
@@ -20,7 +20,7 @@ Relevant Team(s): Fill this in with the [team(s)](README.md#relevant-teams) to w
 RFC PR: Fill this in with the URL for the Proposal RFC PR
 -->
 
-# <RFC title>
+# Deprecate the use of `get`/`set` in test contexts
 
 ## Summary
 

From 92b99e4afe9ac637abb91dfa0bebc4a9bd781d46 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Fri, 7 Jan 2022 12:43:28 -0700
Subject: [PATCH 10/13] add PR number

---
 ...move-set-get-in-tests.md => 0785-remove-set-get-in-tests.md} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename text/{0000-remove-set-get-in-tests.md => 0785-remove-set-get-in-tests.md} (99%)

diff --git a/text/0000-remove-set-get-in-tests.md b/text/0785-remove-set-get-in-tests.md
similarity index 99%
rename from text/0000-remove-set-get-in-tests.md
rename to text/0785-remove-set-get-in-tests.md
index d65e187304..32154b92b1 100644
--- a/text/0000-remove-set-get-in-tests.md
+++ b/text/0785-remove-set-get-in-tests.md
@@ -6,7 +6,7 @@ Release Versions:
   ember-source: vX.Y.Z
   ember-data: vX.Y.Z
 Relevant Team(s): Ember
-RFC PR:
+RFC PR: https://github.com/emberjs/rfcs/pull/785
 ---
 
 <!---

From d314b8ac2588450c525a4bc5a9886de3b248b0d6 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Mon, 10 Jan 2022 11:23:45 -0700
Subject: [PATCH 11/13] better title

---
 text/0785-remove-set-get-in-tests.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0785-remove-set-get-in-tests.md b/text/0785-remove-set-get-in-tests.md
index 32154b92b1..4e5e1c29cb 100644
--- a/text/0785-remove-set-get-in-tests.md
+++ b/text/0785-remove-set-get-in-tests.md
@@ -20,7 +20,7 @@ Relevant Team(s): Fill this in with the [team(s)](README.md#relevant-teams) to w
 RFC PR: Fill this in with the URL for the Proposal RFC PR
 -->
 
-# Deprecate the use of `get`/`set` in test contexts
+# Introduce new test helpers for rendering (and re-rendering) that obviate the need for `get` and `set`
 
 ## Summary
 

From 199849ceeb368ab49973929e741cda305d502784 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Fri, 18 Mar 2022 11:20:07 -0600
Subject: [PATCH 12/13] use FCCTs instead of scopedTemplate

---
 text/0785-remove-set-get-in-tests.md | 76 +++-------------------------
 1 file changed, 7 insertions(+), 69 deletions(-)

diff --git a/text/0785-remove-set-get-in-tests.md b/text/0785-remove-set-get-in-tests.md
index 4e5e1c29cb..3db1c60b46 100644
--- a/text/0785-remove-set-get-in-tests.md
+++ b/text/0785-remove-set-get-in-tests.md
@@ -58,12 +58,13 @@ The goal of this RFC, then, is to greatly simplify the testing model by removing
 
 ## Detailed design
 
-We will introduce several new/refactored utilities for use in rendering tests:
+We will introduce two new/refactored utilities for use in rendering tests:
 
 1. Update the `render` helper to accept either a component or a template snippet.
-1. A new `scopedTemplate` function that accepts a template and returns a component _that uses lexically scoped data_
 1. A new `rerender` function that would be used after the initial `render` call to wait for DOM updates
 
+These additions, used in concert with [First Class Component Templates](https://github.com/emberjs/rfcs/blob/master/text/0779-first-class-component-templates.md), should significantly improve the DX of writing component tests in Ember.
+
 ### Updated `render` helper
 
 Rendering tests currently work by rendering a template that is bound to the `this` of the surrounding test. This is why developers have to call `this.set` in the first place, since the value of `this` in a given test is doing double duty as both the actual test context AND the backing object for the template that eventually gets rendered. Since we want to move away from this very behavior, we need a version of `render` that can alternatively accept a fully-formed component, since components have their own context and are self-contained.
@@ -74,43 +75,6 @@ The updated version of `render` would be imported from `@ember/test-helpers` and
 function render(template: TemplateFactory | Component, options?: RenderOptions): Promise<void>;
 ```
 
-### `scopedTemplate`
-
-Now that we have a new version of `render`, we also need a convenient way of creating components to pass to it. This is where the `scopedTemplate` function comes in. `scopedTemplate` would accept a [strict-mode](https://github.com/emberjs/rfcs/blob/master/text/0496-handlebars-strict-mode.md) template and return a renderable component which could then be passed to our updated version of `render`:
-
-```ts
-function scopedTemplate(templateString: string): Component;
-```
-
-Much like `hbs`, `scopedTemplate` would be a Babel macro, meaning it could be invoked like a function (e.g. `scopedTemplate('<Foo />')`) or like a tagged template string (e.g. `` scopedTemplate`<Foo />` ``), and it does _not_ accept any kind of string interpolation or concatentation (i.e.`` scopedTemplate`<Foo @name=${'blah'} />` `` is not allowed).
-
-In addition, the template passed to `scopedTemplate` would have access to lexically scoped data, meaning that its values would pull _directly from the surrounding scope_, i.e. the values defined in the test itself. With this new approach, instead of having to call `this.set` for each value you want to reference in the template, you instead just define the data you want and reference it directly in the template. For example:
-
-```js
-import { render } from '@ember/test-helpers';
-import { scopedTemplate } from '@ember/template-compilation';
-
-// setup elided
-test('it works', async function (assert) {
-  const somePerson = {
-    name: 'Zoey',
-    age: 5,
-  };
-
-  const component = scopedTemplate`
-    <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
-  `;
-
-  await render(component);
-
-  assert.dom(this.element).hasText(somePerson.name);
-});
-```
-
-In the (near?) future, a proposal like `<template>` from [RFC #0779](https://github.com/chriskrycho/ember-rfcs/blob/fcct/text/0779-first-class-component-templates.md) could supersede `scopedTemplate`, as the components created with first-class component templates could be passed directly to `render` as well. This RFC can move forward and use lexical scoping _without_ requiring that full feature set to be implemented, however.
-
-Since `scopedTemplate` would require a strict-mode template, it would be supported back to v3.25. (If we had to also support loose mode, it'd only work starting in 3.28).
-
 ### `rerender`
 
 Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd _usually_ just update the values using `this.set`, which immediately triggers a rerender. In more complex cases, e.g. where there is some async operation involved, we would wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`).
@@ -129,7 +93,6 @@ Continuing the example from above, here's what we'd expect an update and re-rend
 
 ```js
 import { render, rerender } from '@ember/test-helpers';
-import { scopedTemplate } from '@ember/template-compilation';
 import { tracked } from '@glimmer/tracking';
 
 // setup elided
@@ -139,9 +102,9 @@ test('it works', async function (assert) {
     @tracked age = 5,
   };
 
-  const component = scopedTemplate`
+  const component = <template>
     <ProfileCard @name={{somePerson.name}} @age={{somePerson.age}} />
-  `;
+  </template>;
 
   await render(component);
 
@@ -163,9 +126,7 @@ We'd need to update the [testing components](https://guides.emberjs.com/release/
 
 We'd also need to update the [API docs for @ember/test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` function.
 
-Finally, we'd need to document the new `scopedTemplate` function in `@ember/template-compilation`.
-
-API documentation for the three new functions are included below:
+API documentation for the two new functions are included below:
 
 ### render
 
@@ -193,24 +154,7 @@ render(template: CompiledTemplate | Component, options?: RenderOptions): Promise
 rerender(): Promise<void>
 ```
 
-### scopedTemplate
-
-```ts
-/**
- Turns a lexically scoped strict-mode template into a Component. The string passed to `scopedTemplate` may not contain
- any interpolated values or other dynamic elements, but it may refer to other values/variables in the surrounding scope.
- @public
- @param {string} templateString a string containing a strict-mode template
- @returns {Component} a component that can be passed to `render`
- @example
-     let person = { name: 'Chris' };
-     scopedTemplate('<Foo @name={{person.name}} />`)
- **/
-
-function scopedTemplate(templateString: string): Component;
-```
-
-All things considered, the changes in this RFC should result in a component testing model that is ultimately _more_ intuitive. We could also introduce a configuration option to `@ember/test-helpers` that would allow users to turn on assertion that prevents rendering tests from being written using the old method to help codebases migrate.
+All things considered, the changes in this RFC should result in a component testing model that is ultimately _more_ intuitive. We could also introduce a configuration option to `@ember/test-helpers` that would allow users to turn on an assertion that prevents rendering tests from being written using the old method to help codebases migrate.
 
 ## Drawbacks
 
@@ -220,14 +164,8 @@ Ember's testing setup is one its most valuable features, and this RFC would intr
 
 - Leave things as they are.
 - Encourage people to use `precompileTemplate` along with the current version of `render`.
-- Only implement the changes to `render` and wait for first-class component templates rather than introducing `scopedTemplate`
-  - That said, the upside to implementing `scopedTemplate` along with the changes to `render` is that it would use the same primitives as first-class component templates, which allows tests written using `scopedTemplate` to be codemodded easily and safely, and allows us to moving the state of rendering tests forward without having to wait on the much larger first-class component template implementation. In addition, implementing `scopedTemplate` sooner provides a lot of value to TypeScript users immediately.
 
 ## Unresolved questions
 
-- Should we also support loose-mode templates for `scopedTemplate` in some way?
-  - This has the benefit of being more flexible and slightly better-suited to today's Ember template.
-  - On the other hand, the future of Ember templates is exclusively strict mode, and this RFC is really aimed at 4.0 and beyond, so support loose-mode may end up be an added cost without much additional value.
-
 > Optional, but suggested for first drafts. What parts of the design are still
 > TBD?

From 040af6f486636ea947a448253acdebd760dec156 Mon Sep 17 00:00:00 2001
From: Chris Freeman <cfreeman.code@gmail.com>
Date: Wed, 6 Apr 2022 09:12:34 -0600
Subject: [PATCH 13/13] feedback

---
 text/0785-remove-set-get-in-tests.md | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/text/0785-remove-set-get-in-tests.md b/text/0785-remove-set-get-in-tests.md
index 3db1c60b46..990662e0d5 100644
--- a/text/0785-remove-set-get-in-tests.md
+++ b/text/0785-remove-set-get-in-tests.md
@@ -75,6 +75,10 @@ The updated version of `render` would be imported from `@ember/test-helpers` and
 function render(template: TemplateFactory | Component, options?: RenderOptions): Promise<void>;
 ```
 
+Since this new version of `render` will need to differentiate between components and templates, we'll also add an `isComponent` utility to the `@glimmer/runtime` package. This addition will significantly reduce the amount of private API that would be required when implementing the new `render` function.
+
+Additionally, since passing a component to `render` also precludes the user from being able to access the text context via `this` (since components will use their own local context rather than the test's), we'll display a warning message if someone passes a component to `render` while also using `this.set` in the same test. This will help avoid confusion in the case that they opt in to the new component-based testing model but then copy an example from the guides or an older writeup that uses `this.set`.
+
 ### `rerender`
 
 Finally, we need to handle cases where you want to update the backing data and assert against the resulting changes in the rendered output. In the current testing paradigm, we'd _usually_ just update the values using `this.set`, which immediately triggers a rerender. In more complex cases, e.g. where there is some async operation involved, we would wait for the state we want to assert against, likely using either `settled` or `waitFor`. This works, but has the downside of either waiting for _everything_ to finish (in the case of `settled`), or waiting for a single thing to finish (in the case of `waitFor`).
@@ -122,7 +126,9 @@ It's worth noting that rendering tests without `get`/`set` are actually possible
 
 ## How we teach this
 
-We'd need to update the [testing components](https://guides.emberjs.com/release/testing/testing-components/) section of the official guides to document this new approach.
+We'd need to add a new TypeScript-specific section to the [testing components](https://guides.emberjs.com/release/testing/testing-components/) section of the official guides to document this new approach for TypeScript users.
+
+We expect there will be a future RFC that introduces a form which also allows passing arguments into the invoking component, in addition to the approach described in this RFC that requires a backing class in order to mark primitives as tracked. As a result, for the time being, we'll only teach this new approach in a TypeScript-specific subsection of the guides on testing components until that followup RFC has been written and merged. We believe that the benefits to the TypeScript community (namely, no longer needing to fight with the type checker over the type of `this` in each test) still significantly outweigh the costs of the slightly awkward method of passing arguments.
 
 We'd also need to update the [API docs for @ember/test-helpers](https://github.com/emberjs/ember-test-helpers/blob/master/API.md) for the new version of `render` as well as the newly introduced `rerender` function.