I wish there were a way to share this test case/make it easily reusable since it'll be needed everywhere, but I'm not sure what that would look like

I was considering putting it all in a single file, within src/compiler/test/test-buildDom. Then we could abstract out a testBuildDom that takes in a tagName and Ctor.

I like that idea, but it seemed to get more complicated when I thought through it. The helper would need some way of getting the buildDom function itself from the tagName, or it would have to be passed in, right? I was thinking the helper could take element, Ctor, and buildDom possibly

You're right, I forgot about buildDom, it would need that too. So the test file would look like:

const tests = [
  {tagName: 'amp-fit-text', buildDom: fitTextBuildDom, Ctor: AmpFitText },
  ...
]

tests.forEach(({Ctor, tagName, buildDom})=> {
  it('buildDom and buildCallback should result in the same outerHTML', () => {
     const el1 = createElementWithAttributes(tagName, {height: 10, width: 10});
     const el2 = el1.cloneNode(true);

     await (new Ctor(el1).buildCallback())
     buildDom(el2);
     expect(el1.outerHTML).to.equal(el2.outerHTML)
  })
})

I disliked the idea when it was a helper function that different test files would import, but seeing it like this where all the components and functions/ctors are listed in one place, I like it much more. We can even do it(`${tagName} - buildDom..` => {...}) so the test output is a bit more meaningful.

hah, i asked about this about a moon ago. where should the file live?

Is there a file anywhere that will be creating/exporting the instruction map? If so, it would make a lot of sense for this to be something like test-instruction-map and then the file itself would have a const constructorMap and compare the results

Yes. Within src/compiler/builders.js...but I'm not confident src/compiler is the right directory for this test

Neither am I. Maybe we export a helper function that takes tagName, Ctor and itself uses the instruction map to look up the buildDom function, that way calling code can do something like itMatchesBuildDom('amp-fit-text', AmpFitText); or something like that

FMI: What's the difference between building these two ways below?
1:

new AmpFitText(fitText1).buildCallback();

2:

fitText1.buildInternal();

I've always done (2) because it avoids having to export and import the component class, but I'm wondering if there should be any difference in outcome otherwise?

While we are here, would you want another test with runtimeOn: true and await fitText1.whenBuilt()?

For most tests (2) is the more correct thing to do. Since we want to simulate everything the Runtime would do. That makes sense when testing the component's behavior. All the classNames additions etc. are required. In order to use (2), you also need to add the element to the document or else there will be errors finding the ampdoc.

For these tests, the goal is to ensure buildCallback and buildDom result in the same DOM Mutations -- completely isolated from the rest of the mutations that would occur during Runtime bootstrap of an element.

As an example, i-amphtml-notbuilt is during createdCallback flow of the CE after being added to the DOM. buildInternal will then remove that. This sequence of classNames is unrelated to what I'd like to test

I see, this helps a lot. Thanks for the explanation!

I'm really not confident about the "most tests" part. Don't have a great understanding of what we want "unit test" to mean for components (i.e. runtime on or no)