Тестовый код SQLITE к производству кодирует отношение

Смотрим на раздел 3.1 (OOM):

Тестирование OOM выполняется путем имитации ошибок OOM. SQLite позволяет приложению подставлять альтернативную реализацию malloc() используя sqlite3_config(SQLITE_CONFIG_MALLOC,...) интерфейс. Тесты TCL и TH3 способны вставить модифицированную версию malloc(), которую можно подстроить так, чтобы она не срабатывала после определенного количества выделений. Эти инструментальные malloc могут быть настроены так. чтобы отказать только один раз, а затем начать работать снова, или продолжать отказывать после первого сбоя. Тесты OOM выполняются в цикле. На первой итерации цикла, инструментальный malloc подстраивается так, чтобы отказать при первом выделении. Затем выполняется некоторая операция SQLite выполняется и проверяется чтобы убедиться, что SQLite правильно обработал ошибку OOM правильно. Затем счетчик времени до отказа счетчик времени до отказа на инструментальном malloc увеличивается на единицу, и тест повторяется. Цикл продолжается до тех пор, пока пока вся операция не завершится ни разу не столкнувшись с имитацией сбой OOM. Подобные тесты проводятся дважды, один раз с инструментом malloc, настроенным на отказ только один раз, и снова с инструментальным malloc, настроенным на непрерывный отказ после первого сбоя.

Обратите внимание, что в разделе 7 явно указано 100% покрытие ядра, определяемое gcov. Я согласен с Donal Fellows, что тестовый фреймворк в значительной степени отвечает за тестовое покрытие, выходящее за рамки того, что можно было бы предположить по графу вызовов. Совсем другое дело - увидеть, что malloc() вводится nn раз и написать для этого тест, чем написать десятки тестов, предназначенных для моделирования окружения, в котором malloc(), скорее всего, не сработает.

Да, полученное покрытие - это артефакт усердия, однако выбор тестового фреймворка, который обеспечивает такое усердие, тоже.

Наконец, повторяя очевидное, malloc() принимает только один указатель void. Это говорит о том, что тесты, написанные вокруг нее, были разработаны намеренно, а не сгенерированы автоматически.

Он использует Tcl для поддержки инфраструктуры тестирования, поэтому писать тесты намного проще, чем писать реализацию. Это способствует тщательному тестированию, а это именно то, что вам нужно в базе данных, да? Более того, значительная часть этих тестов являются проприетарными и предназначены для тестирования во встроенных средах; Я предполагаю, что какой-то корпоративный пользователь (или пользователи) заплатил за подобные вещи. Также вполне возможно, что одна и та же функция тестируется несколько раз.

«Кто-нибудь знает, как это возможно?»

«Возможно» иметь в 679 раз больше тестового кода, потому что одна функция может быть используется по-разному. Рассмотрим только одну функцию, которая принимает два параметра. Я могу сгенерировать много тестового кода для этой функции, которая проверяет граничные условия и многие другие комбинации условий. Когда вы рассматриваете настройку / разборку тестов, там есть дополнительный код. В зависимости от их среды тестирования эти накладные расходы могут значительно увеличить объем кода при тестировании.

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

Это возможно, если разработчики потратили на написание тестового кода в 679 раз больше времени, чем на написание производственного кода. Подумайте только: если бы они выбрали вместо этого в 339 раз больше тестового кода, у них могло бы быть два целых движка базы данных, каждый из которых по-прежнему обладал бы смехотворным количеством тестового покрытия.

Однажды я наблюдал, как товарищ-разработчик пытался успокоить разъяренного клиента по поводу просрочки сроков, сообщая им, что он написал в 5 раз больше тестового кода, чем производственного кода. Заказчик был не успокоен, если вы можете себе представить. По крайней мере, я не думаю, что покрытие 5X больше является экстремальным.