кто записал тесты 250k для 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» и "arrow-keys-on-body-expected.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.

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

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

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

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

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

• Легко: напишите html-страницу (или аналогичный ввод в черный ящик), чтобы проверить функциональность / особенности / поведение
• Необходимо:
  1. Необходимо протестировать / проверить функциональность, когда она написана
  2. Необходимо продемонстрировать / воспроизвести ошибки при заполнении любого отчета об ошибках
  3. Необходимо сохранить все предыдущие тесты с 1. и 2. для проведения регрессионного тестирования

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

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

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

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

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

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

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

Учитывая, что существует только 18 000 уникальных тестов и 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.······
----------

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

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

... и ...

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

Возможно, ответы на ваши вопросы можно найти в WebKit Committers and Reviewer Policy .

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

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

• Написание юнит-тестов - довольно распределенное занятие. Армии интернов/добровольцев могут делать это параллельно.