Recently (T373405) we had a bug which caused isParsoidContent not to be set, which caused all of the Parsoid-specific post processing steps in OutputTransform stages to be skipped. This was a silent failure, and we'd like to write a test case to prevent something like this from happening again.

Since parsoid read views aren't *quite* accessible in core yet, there are probably two steps here:

• Write a selenium test for the ParserMigration extension which passes useparsoid=1 as a URL query string and verifies that at least some expected features of Parsoid output are present.
  • section edit links, parsoid-specific class names, what else would be useful?
• Add the ParserMigration extension to the mw-gate set so that it is run during gate-and-submit and any patches which cause our new selenium test in ParserMigration to fail will be blocked from merge.