Герметичные модульные испытания

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

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

Например, рассмотрим рисунок 1, который принимает в качестве аргумента хеш из внешнего API. Этот хеш-код содержит температуру в градусах Цельсия, которая to_fahrenheitконвертируется в градусы Фаренгейта.

def to_fahrenheit(api_return)
  (api_return[:temperature] * 9/5) +32
end
Figure 1: Arbitrary Ruby method to coverting Celsius to Fahrenheit

class TestMeme < Minitest::Test
  def setup
    @fake_api_return = {temperature: 100}
  end

  def test_to_fahrenheit
    assert_equal 212, to_fahrenheit(@fake_api_return)
  end
end
Figure 2: Hermetic Unit Test of to_fahrenheit using Ruby minitest