IIRC, dbeam@, michaelpg@, and I were all pretty excited about the iron icon test, since it effectively ensured that the developer actually included the file that defined the icon image (which is not something that's usually tested automatically).  I'd be a little sad to see it go, assuming it still worked to detect these issues.*  If we can find a reasonably simplistic, efficient-ish way of doing this, it seems like it may be worthwhile.  (An alternative would be suggesting each WebUI implement a test that call a testIronIcons() method or a single testIronIcons() method that navigates to each webui - either of those seem harder to maintain, since we'd have to manually update the set of what to test.)

*Polymer has changed, so if this *doesn't* still detect issues, we should either find another way or scrap it.

this is really testing my memory, but I'm pretty sure we created this test because missing-icon bugs kept happening. Unfortunately we can't know how many bugs the test function has prevented.

it's a shame iron-icon doesn't just assert that _svgIcon gets set when it calls iron-iconset-svg's applyIcon().

Do we know how slow (1) would really be? I understand it's not super efficient, but I doubt it would noticeably affect test durations.

> Do we know how slow (1) would really be? I understand it's not super efficient, but I doubt it would noticeably affect test durations.

Have not tried this yet, but the code I had in mind can be seen at [1] (see findMatchingElements function). This was in a review's intermediate patch and ended up not landing, so we would need to revive that function.

@rbpotter: Had done some bencmarking at the time, since this was originally meant to be used in Settings' search. I don't recall the exact numbers but IIRC it was significantly slower.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1100102/1/ui/webui/resources/js/search_highlight_utils.js