Моделирование условий гонки в модульных тестах RSpec

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

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

class TestSubject

  def insert_unless_exists
    if !row_exists?
      insert_row
    end
  end

end

Но этот код работает на нескольких компьютерах. Таким образом, возникает состояние гонки, поскольку другой процесс может вставить строку между нашим тестом и нашей вставкой, вызывая исключение DuplicateKey. Мы хотим проверить, обрабатывает ли наш код исключение, возникающее в результате этого состояния гонки. Для этого наш тест должен вставить строку после вызова row_exists?, но перед вызовом insert_row. Итак, давайте добавим тестовый хук прямо туда:

class TestSubject

  def insert_unless_exists
    if !row_exists?
      before_insert_row_hook
      insert_row
    end
  end

  def before_insert_row_hook
  end

end

При запуске в дикой природе хук ничего не делает, кроме того, что съедает немного процессорного времени. Но когда код тестируется на состояние гонки, тестовая обезьяна-патч перед_insert_row_hook:

class TestSubject
  def before_insert_row_hook
    insert_row
  end
end

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

Эта идея так же проста, как курсор XOR, поэтому я подозреваю, что многие программисты независимо изобрели ее. Я обнаружил, что это обычно полезно для тестирования кода с условиями гонки. Я надеюсь, что это помогает.