кто написал 250к тестов для webkit?

Из рекомендаций по участию в webkit

«Для любой функции, которая влияет на механизм компоновки, должен быть построен новый регрессионный тест. Если вы предоставите патч, который исправляет ошибку, этот патч должен также включать добавление регрессионного теста, который не прошел бы без патча и завершился бы успешно с патчем. . Если регрессионный тест не предоставлен, рецензент попросит вас отредактировать патч, чтобы вы могли сэкономить время, построив тест заранее и убедившись, что он привязан к ошибке. Если тест макета не может быть (или должен быть) созданный для исправления, вы должны объяснить, почему рецензенту не нужен новый тест ".

В) Кто написал эти тесты? A) Практически все, кто участвовал в разработке webkit.

Исходный каталог содержал 240К файлов:

 Total Files Listed:
       243541 File(s)  1,062,470,729 bytes
       64718 Dir(s)

Многие из них представляют собой файлы svn. Если я удалю все подкаталоги с именем ".svn", количество файлов упадет до 90 КБ:

 Total Files Listed:
       90615 File(s)    537,457,618 bytes
        7190 Dir(s) 

В некоторых каталогах есть подкаталог с именем «resources» и / или «script-tests». Я думаю, что эти подкаталоги содержат вспомогательные файлы, которые используются тестовыми примерами в супердиректориях. Если я удалю эти подкаталоги (потому что они не добавляются к общему количеству тестов), количество файлов упадет до 87 КБ:

 Total Files Listed:
       87672 File(s)    534,598,610 bytes
        6305 Dir(s)

Сжатие «похожих» имен файлов (например, «клавиши со стрелками-on-body.html» и «клавиши со стрелками-на-теле-ожидаемом.txt» - это два файла, которые определяют один тест) уменьшает общее количество с 87 КБ до 43 КБ.

Единственные подкаталоги, которые содержат более 1500 таких тестовых случаев (подсчитанных, как описано выше):

2761   LayoutTests\dom
10330  LayoutTests\fast (of which 5934 are in LayoutTests\fast\js)
22575  LayoutTests\platform (with various O/S-specific subdirectories).

В подкаталогах платформы, похоже, происходило некоторое копирование и вставка между платформами. Например, файл css3-modsel-37-expected.txt существует:

• В подкаталоге LayoutTests\platform\mac\css3
• В подкаталоге LayoutTests\platform\chromium-win\css3
• В подкаталоге LayoutTests\platform\qt\css3.

Если я отброшу имена файлов, которые дублируются в нескольких подкаталогах платформы, то будет только 5716 (вместо 22575) уникальных тестов платформы.

Подводя итог, я думаю, что существует около 18K уникальных тестов: это по-прежнему впечатляющее количество тестов, но меньше, чем 250K, которые вы оценили в своем OP.

Для сравнения я недавно нашел CSS2.1 Test Suite: это примерно 9000 тестовых примеров для CSS.

Я просто написал 4 юнит-теста за 5 минут. Не все модульные тесты занимают много времени. Некоторые очень простые;)

• Есть такие вещи, как генераторы автоматических модульных тестов. Для сложной функции вам часто может потребоваться выполнить все перестановки возможных значений, скажем, 7 параметров. Если они логические, вы получите 2 ⁷ = 128 тестов. Для определенных сценариев все эти 128 тестов генерируются с использованием 10 строк кода.

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

• Написание модульных тестов - довольно распространенное занятие. Параллельно это могут делать армии стажеров / волонтеров.

Это не похоже на модульные тесты: они больше похожи на системные / регрессионные тесты.

Это не дает прямого ответа на ваш вопрос, но я разработал собственный браузер, так что, возможно, я немного разбираюсь в нем; видеть:

• Следует ли тестировать внутреннюю реализацию или тестировать только публичное поведение?
• Тестирование

Может ли какая-нибудь мудрая душа там на ТАК пролить свет на то, какие мифические люди пишут нереальное количество тестов для больших программных проектов?

Такой тест легко и необходимо написать:

• Легко: напишите html-страницу (или аналогичный ввод в черный ящик), чтобы проверить функциональность / особенности / поведение
• Necessary:
  1. Need to test/exercise functionality when it's written
  2. Необходимо продемонстрировать / воспроизвести ошибки при заполнении любого отчета об ошибке
  3. Необходимо сохранить все предыдущие тесты из 1. и 2., чтобы провести регрессионное тестирование.

Один мой начальник однажды сказал: «Вы получаете то, что проверяете». (что означает, что все, что вы не тестируете, неизвестно / случайно).

Это действительно зависит от того, как это было подсчитано.

Но в любом случае, как только будет создана хорошая среда для тестирования определенного класса / библиотеки / модуля / чего угодно, добавление нового теста обычно занимает всего несколько строк. Если бы они писали тесты с целью достижения высокого процента покрытия кода, то эти тесты обычно были бы еще короче, потому что вы выполняете множество тестов, которые различаются только значением одной переменной, чтобы получить другой путь кода.

Ваш анализ в лучшем случае неполный. Или, наверное, предвзято.

Вы должны подсчитать количество тестировщиков, некоторые (или все) из которых полностью посвящены тестированию и только тестируют, что делает их более продуктивными. Кроме того, вы должны понимать, что очень немногие тесты являются сложными во многих проектах, и большинство тестов могут быть повторяющимися, поэтому их можно легко реализовать.

В комментариях вы спросили:

кто наблюдает за наблюдателями? у кого-то должна быть кошмарная работа пасти всех этих утят

... и ...

да, вы задаете тот же вопрос, что и я. сколько там было тестеров. кто они. они разработчики или сотрудники отдела контроля качества? волонтеры?

Возможно, ответы на ваши вопросы можно найти в Политике коммиттеров и проверяющих WebKit.

предполагая производительность 3 в час, это 83000 часов

Учитывая, что существует только 18K уникальных тестов и 200 рабочих дней на человека в год, тогда, если вы выделите целый день на разработку каждого теста, тогда команда из 9 штатных тестировщиков / человек может разработать 18K тестов за 10 лет ( KDE проекты KHTML и KJS начались в 1998 году). Эти цифры, вероятно, несущественны (может не потребоваться день для разработки каждого нового тестового примера, и у них может не быть штатных / выделенных тестировщиков), но они действительно показывают, что ИМО показывает, что 18K тестов за 10 лет выполнимы для `` большого '' ( или нетривиально), успешный проект.

Я использую аналогичную стратегию тестирования в своем проекте: не потому, что я скопировал Webkit, а потому, что это единственный способ, который я думаю, выполнять автоматизированные, но поддерживаемые регрессионные тесты графического интерфейса.

Следующий FYI - это пример (один из самых коротких / простых примеров) одного из моих тестовых примеров. Я генерирую его (и другие подобные ему), просто вручную проверяя пользовательский интерфейс своего браузера во встроенной среде генерации тестовых случаев. Затем я могу снова запустить его позже в качестве автоматического регрессионного теста (фреймворк воспроизводит ввод и утверждает, что вывод не изменился).

Я считаю, что создание тестовых примеров - это не то, что занимает относительно много времени.

> clientSize 20 10
+ screenDisplays lines 0
----------
----------
> loadDocument lines 5
----------
<div>
<h1>Easy title</h1>
<p>Hello world. Lorem ipsum.</p>
<p>Embedded <a>anchor</a> tag.</p>
</div>
----------
< invalidateAll
> paint 0 0 20 10
+ screenDisplays lines 10
----------
····················
····················
··»«Easy title········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> mouse down 9 2
< ensureVisible 9 2 1 13
+ screenDisplays lines 10
----------
····················
····················
··Easy ti»«tle········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> mouse up 9 2
< ensureVisible 9 2 1 13
+ screenDisplays lines 10
----------
····················
····················
··Easy ti»«tle········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> keyDown Enter
< invalidate 2 2 16 1
< invalidateAll
< invalidate 2 4 16 3
< ensureVisible 2 5 1 16
+ currentDocument lines 6
----------
<div id="ModelText_id_contents">
 <h1>Easy ti</h1>
 <h1>tle</h1>
 <p>Hello world. Lorem ipsum.</p>
 <p>Embedded <a>anchor</a> tag.</p>
</div>
----------
+ debugDumpDom lines 15
----------
 1  div
 2    h1
 3      Easy ti
 4    h1
 5      tle
 6    p
 7      Hello world. Lorem ipsum.
 8    p
 9      Embedded 
10      a
11        anchor
12       tag.

Selected start={parentId=4,parent={tle},offset=0}, end={parentId=4,parent={tle},offset=0}

----------
> paint 0 0 20 10
+ screenDisplays lines 10
----------
····················
····················
··Easy ti···········
····················
····················
··»«tle···············
····················
····················
··Hello world. ·····
··Lorem ipsum.······
----------