Я работаю над веб-платформой с 2010 года. Я перешел в команду разработчиков Internet Explorer из SharePoint Designer, чтобы помочь с IE9, и с тех пор работаю здесь. В то время Chrome почти не поставлялся. Версия Chrome 4.0 (в то время все еще основанная на webkit) и Firefox версии 3.6 (под управлением Gecko) вышли примерно в тот же день, когда я начал работать с IE. Но для ясности: нас не особо интересовал Chrome. Конечно, это было мило и быстро, но настоящим конкурентом был Firefox. Mozilla решительно утверждала, что они являются «носителями стандартов» (напрямую конкурируя с Opera за эту роль), и мы решили конкурировать с ними на арене стандартов.

Во время разработки IE8 команда начала экспериментировать с стандартным режимом, который позволил бы Microsoft поставлять режим, поддерживающий стандарты, а также режим, поддерживающий совместимость с устаревшими системами. Для реализации стандартного режима инженеры Microsoft написали множество тестов. Много. И мы сделали некоторые из них публичными, пожертвовав их W3C. Эти заявки были сделаны до того, как появился проект Тесты веб-платформы. Мы отправили тесты в тестовые репозитории отдельных рабочих групп, а затем сообщили о результатах отправленных тестов. Мы также участвовали во многих мероприятиях Test the Web Forward, чтобы помочь тем, кто был заинтересован, представить свои собственные тесты. Я бы сказал, что те мероприятия прошли не очень хорошо (конечно, они были веселыми, и мы получили от них несколько тестов, но многие пришлось отклонить из-за низкого качества).

Оказывается, для написания хороших тестов этого кода действительно требуются эксперты в коде. Думаю, однажды я напишу об этом более конкретно.

Так или иначе: мы активно участвовали в тестировании стандартов и активно конкурировали с Firefox, который воспринимался как носитель стандартов. Итак, как лучше всего бороться с этим восприятием? Работайте над его изменением…

Когда мы отправляли тесты в W3C, некоторые насмехались над нами за то, что мы представили только часть тестов, которые мы на самом деле написали. Это было правдой: мы не сдавали все наши тесты. Другие предположили, что мы просто хотим предоставить тесты, которые прошли, и сохранить в секрете все сбои. Это верно лишь частично. Мы действительно прошли почти 100% тестов, которые мы написали, даже внутренние, потому что странно проверять тест, который терпит неудачу. Вдобавок мы по ходу дела отправили несколько неудачных тестов (например, flexbox-тесты), потому что это позволило нам более легко показать прогресс.

Так почему это проблема?

Как было сказано выше: написание тестов требует опыта. Это также требует очень много времени. Поэтому это очень дорого. Для всех новых функций, поступающих через W3C, Microsoft представила тесты, которые показали, что мы прошли почти 100% по стандартам, а также что Firefox прошел только 90% или около того (что интересно, и в ретроспективе это действительно очень важный факт: Chrome также были на отметке 100% по новым функциям, и когда я пытался продемонстрировать, что они не соответствуют стандартам, это было очень сложно сделать). Таким образом, большинство тестов, которые были публично использованы, были написаны Microsoft, и в основном они касались только новых функций. Для устаревших функций было несколько тестов, и, конечно же, были кислотные тесты, но как только вы их пройдете, вы двинетесь дальше. Они никогда не предназначались для того, чтобы продолжать расти в размерах и масштабах, как это сделали бы тесты веб-платформы.

Из всего этого я понял, что тот, кто контролирует тесты, начинает контролировать восприятие. И наша теория игр оказалась верной: Firefox должен был выделить инженеров для исправления сбоев публичных тестов. Им пришлось выделить инженеров для написания тестов, чтобы Microsoft не контролировала всю историю. Альтернативная стоимость этого означала, что им приходилось медленнее создавать новые функции. Однако выяснилось, что этот подход к играм не сработал против Google. В то время как мы были сосредоточены на Mozilla и их ограниченных инженерных ресурсах, Google решил бросить столько тел, сколько необходимо. И они проделали действительно (действительно, (действительно)) хорошую работу по реализации функций, написанию тестов и демонстрации стандартов в своем (теперь разветвленном) движке: Blink (по иронии судьбы названный в честь нестандартной функции от Netscape Navigator).

В 2017 году Chrome включил двустороннюю синхронизацию между исходным кодом Chromium и тестами веб-платформы. Это звучит как добро: это означает, что Chromium постоянно тестируется на соответствие стандартам, и что регресс в стандартах приведет к тому, что изменения будут сохранены из источника. Конечно, тесты, которые в настоящее время терпят неудачу, по-прежнему будут неуспешными, но для их прохождения потребуется по крайней мере новые тесты. И это хорошо. Это…

Но ты видишь, куда я иду?

Новые функции Chromium должны включать тесты. Если эти тесты не пройдут, слияние, скорее всего, будет отклонено. Затем эти тесты автоматически синхронизируются с тестами веб-платформы. Добавление любых дополнительных тестов, которые Chromium может не выполнить, требует опыта другого эксперта по функциям. Раньше одним из этих экспертов была Microsoft с EdgeHTML, но сейчас это уже не так. Может быть, инженеры Opera могли бы это сделать, но теперь они тоже основаны на Chromium, а Presto больше нет. И так снова падает на Mozilla.

Из текущей приборной панели (wpt.fyi, написанной в основном Google) видно, что Chrome проходит больше тестов, чем любой другой движок. И они будут продолжать предоставлять тесты для новых функций, которые также пройдут 100% тестов. И единственный способ, которым Mozilla изменится, - это если они будут отправлять тесты с той же скоростью, что и Chrome. Вы можете подумать: Эй, Джон, подожди. «Firefox также имеет двустороннюю синхронизацию, разве они не делают то же самое? » Что ж, они могли бы, за исключением того, что им приходится тратить столько времени на исправление ошибок, как это видно на wpt.fyi, они действительно не могут играть здесь в теорию игр. Также бывает, что разработчики рассматривают Chrome как де-факто стандарт и в любом случае не обращают особого внимания на результаты тестирования, кроме своих собственных.

Хорошо, так что я на самом деле хочу сказать?

Отрасль измеряет соответствие стандартам с помощью наборов тестов, которые не обязательно тестируют то, что нам как веб-разработчикам небезразлично, таким образом, чтобы они никогда не использовались в реальном коде и не отображали полную картину состояния реализации. Из подхода Microsoft я понял, что на самом деле мы не улучшали стандарты для различных браузерных движков. Мы улучшали восприятие стандартов в нашем двигателе и (надеюсь) управляли другими двигателями, чтобы соответствовать нашим результатам. Что это не показывает нам, так это все области, в которых мы не можем значимым образом соответствовать стандартам с помощью всех этих новых функций. Когда мы, наконец, проходим все тесты в HTML, например, означает ли это, что у нас есть взаимодействие? Нет. Это означает, что мы прошли все тесты, которые (в первую очередь) Chromium представил для этой функции. Должен признать, что, изучая кодовую базу Chromium, я был весьма впечатлен тем, насколько она хороша на самом деле, но меня немного беспокоит возможность взаимодействия в долгосрочной перспективе. Кто будет тестировать все случаи, когда Chromium дает сбой, но о которых никто не знает из-за отсутствия тестов? Кто проверяет границы взаимодействия двух функций? Кто тестирует совместимость сквозных сценариев? И кто помогает расставить приоритеты по этим ошибкам с максимальной выгодой для веб-разработчиков?

Думаю, это зависит от всех нас. Если вы достаточно заботитесь об этом, чтобы дойти до этого момента в публикации, я думаю, вам следует потратить некоторое время, чтобы изучить тесты в функции, которая вам небезразлична, научиться писать тесты для этой функции, а затем протестировать дерьмо из этого. Может быть, Chromium пройдет все ваши тесты. Может быть, вы не совсем знаете, действительны ли ваши тесты (кстати, как бы вы их проверяли, кроме запуска в Chrome?). Возможно, вы обнаружите существенный пробел в стандартах, который иначе остался бы незамеченным, и, возможно (только возможно), вы поможете протестировать Интернет.

Предупреждение! Предупреждение

  1. Я немного помог с wpt.fyi, и моя команда работает над включением Azure Pipelines для запусков автоматизации, включением нового браузера Edge для отчетов о результатах и ​​помощи в разработке отчетов. Я действительно ценю такой вид панели инструментов, и я думаю, что Филип Ягенштедт отлично справляется с этим. Панель управления не виновата в том, что набор тестов неполный.
  2. Некоторые тесты вообще не имеют значения для разработчиков. Например, в спецификации может быть сказано, что значение ДОЛЖНО быть положительным целым числом и что, если будет передано что-то еще, реализация ДОЛЖНА ошибиться, выполнив «foo». Мы пишем тест, который использует строку. Когда мы выполняем тест, мы обнаруживаем, что один браузер выдает ошибку с «foo» (ПРОЙДЕН), а другой (может быть, КАЖДЫЙ другой) с «bar» (FAIL). Разработчику все равно? Несмотря на то, что эти тесты используются, чтобы показать разработчикам, какие функции они могут или не могут использовать на своих сайтах, эти тесты в основном предназначены для поставщиков браузеров, которые пишут браузеры.
  3. Иногда простое исправление для браузера устраняет сотни сбоев. Например, если приведенный выше оператор проверяется с помощью разных строк, отрицательных целых чисел, нуля (который может быть положительным в одном браузере и не положительным в другом), пустым и т. Д. И т. Д., Все они идут по одному и тому же пути кода, который имеет простой ошибка, наличие сотен сбоев не обязательно означает, что в браузере есть сотни ошибок.
  4. Вы можете спросить: «Почему Джон только что не отправил несколько тестов, показывающих сбои взаимодействия?» Думаю, по той же причине, что и у других: время. Но я действительно надеюсь поправиться в этом.