Boris Nagaev

Попробовал протестировать как-то так с использованием stub:

it("calls getEventType with the event", function()
    function getEventType()
      return 3
    end
    stub(_G, "getEventType")
    processEvent(42)
    assert.stub(getEventType).was.called_with(42)
    getEventType:revert()
  end)

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

В итоге протестировал всё без spy, mock и stub. На мой взгляд, если отслеживаемых функций не безумное множество, то лучше по-простому.

Не совсем понятно как правильно загружать код из другого фаила, если код не завернут в модуль.

Используйте функцию dofile. Но лучше делать из тестируемых файлов модули и загружать при помощи require.

Замечание по коду: не злоупотребляйте глобальными переменными.

UPD. В busted ответили, что из-за того busted применяет песочницу для тестов, глобальные переменные имеют область видимости в рамках текущего spec-файла или describe-блока. Предложили, как всё-таки протестировать функцию processEvent (присваивать к полям _G), но это потребовало изменять её код. Мораль такова: не пользуйтесь глобальными переменными.

UPD 2. Советуют объявить глобальные функции в отдельном модуле, который подключать через require в тестах. Тогда глобальные переменные попадут в _G тестов и всё будет работать, как ожидалось. Пример кода взят из ответа:

-- processEvent.lua
function getEventType(e)
  ...
end

function processEvent(e)
  eventId = getEventType(e)
  if eventId == 3 then
    return 3
  else
    return 0
  end
end

-- process_event_spec.lua
require 'processEvent'

describe("processEvent", function()
  it("calls getEventType with the event", function()
    stub(_G, "getEventType")
    processEvent(42)
    assert.stub(getEventType).was.called_with(42)
    getEventType:revert()
  end)
end)

Разработчик пишет, что проблема исправлена. Исправили?

В файле ltable.c сказано следующее:

The actual size of the array is the largest 'n' such that at least half the slots between 0 and n are in use.

Таким образом, массив охватывает ключи от 0 до такого числа n, что используется хотя бы половина. Давайте ещё посмотрим на код функции computesizes, которая решает, каким будет размер массива при изменении размера таблицы. Эта функция перебирает степени двойки (1, 2, 4, 8 ...) и смотрит, какая доля массива была бы занята, если бы он был такого размера. Останавливается, когда эта доля становится меньше половины. Нетрудно доказать, что при таком алгоритме выбора размера массива и при сплошном заполнении всех ключей от 1 до n обязательно будет выбран размер массива, больший или равный n.

Кстати говоря, из этого же следует, что при добавлении в конец массива элементов будут накладные расходы, но не на хеш-часть, а на пустые элементы массива, выделенные "про запас". Но так и должно быть, чтобы не перестраивать массив при каждом новом элементе. (В C++ vector.push_back ведёт себя так же.) Если заранее знаете окончательный размер массива и хотите на этом выгадать, то напишите сишное расширение, которое вызывает lua_createtable(L, размер-массива, 0).

По поводу того, не появится ли хеш-часть при замене значений на различные типы. Не появится. Дело в том, что в паре ключ-значение ключ и значения хранятся в разных полях. Я отследил как используется поле i_val, оказалось только в макросе gval, тип которого нигде не фигурирует (только проверки на nil).

Кроме того, могу посоветовать использовать rawset и lua_rawseti, так как они не проверяют метаметоды, поэтому должны работать быстрее. Про lua_rawseti я уверен, что работает быстрее, а про rawset подозреваю.

Не Lapis+Nginx, но Lua: sputnik.freewisdom.org

Everything is done using Lua. Node storage format? Lua! The permission rules? Lua!