Соотношение тестового кода SQLite к производственному коду

Question

SQLite утверждает, что имеет в 679 раз больше тестового кода, чем производственный. http://www.sqlite.org/testing.html

Кто-нибудь знает, как это возможно? Они генерируют какой-либо тестовый код автоматически? Каковы основные части этих "45678.3 KSLOC" тестового кода?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Глядя на раздел 3.1 (OOM):

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

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

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

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

Answer 4

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