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

Ответ 1

Из руководящие принципы вклада webkit

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

Q) Кто написал эти тесты? A) Практически все, кто внес вклад в вебкит.

Ответ 2

В исходном каталоге содержались 240K файлов:

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

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

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

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

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

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

Единственными подкаталогами, которые содержат более 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).

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

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

... и...

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

Возможно, на ваши вопросы ответят на Политика и рекомендации редактора WebKit.

Ответ 9

при условии выхода 3 в час, что 83000 часов

Учитывая, что существует только 18 тысяч уникальных тестов и 200 рабочих дней на человеко-год, тогда, если вы планируете целый день разрабатывать каждый тест, команда из 9 человек, работающих на полную ставку, может разработать 18-килограммовые тесты в 10 лет (проекты KDE KHTML и KJS начались в 1998 году). Эти цифры, вероятно, неактуальны (для разработки каждого нового тестового примера может потребоваться не один день, и у них могут не быть полноправных/посвященных тестировщиков), но они показывают ИМО, что 18-килограммовые тесты более 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.······
----------