Код теста SQLite для кода производственного кода

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

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

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

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

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

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

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

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

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

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

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

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

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