in java ~ read.
Apache Thrift стимулирует писать тесты

Apache Thrift стимулирует писать тесты

Не так давно, в качестве эксперимента, мы решили попробовать использовать Apache Thrift в наших проектах. Сам по себе Thrift представляет собой такой слоёный пирог из нескольких уровней, который позволяет организовать взаимодействие между различными компонентами системы в RPC-стиле, миксуя его отдельные слои так, как это нужно разработчику:

  +-------------------------------------------+
  | Server                                    |
  | (single-threaded, event-driven etc)       |
  +-------------------------------------------+
  | Processor                                 |
  | (compiler generated)                      |
  +-------------------------------------------+
  | Protocol                                  |
  | (JSON, compact, binary etc)                       |
  +-------------------------------------------+
  | Transport                                 |
  | (raw TCP, HTTP etc)                       |
  +-------------------------------------------+

Чаще всего для коммуникации выбирается бинарный протокол, а не JSON, потому что если уж JSON, то с ним лучше справляются сервисы написанные в REST-стиле, а не в RPC.

Основная проблема бинарного протокола заключается в том, что для тестирования работы сервиса извне этого сервиса, необходим клиент, сгенерированный по специальным .thrift файлам, в которых указана спецификация сервиса. Найти вменяемый GUI-клиент наподобие SOAPUI или Postman-а мне не удалось (буду признателен, если кто поделится ссылкой на сие чудо). Но тестировать то свой сервис как-то нужно, и тут есть два способа:

  1. В development режиме подсовывать JSON-протокол и HTTP-транспорт. Тогда все вызовы можно делать из того же Postman-а.
  2. Правильный способ - писать тесты.

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

Сами тесты для Thrift-а пишутся очень легко за счёт уже сгенерированных классов. Вот пример хоть и простого, но показательного теста.

Для Gradle-a процесс может быть организован следующим образом:

test {  
    exclude '**/integration/**'
}

task integrationTest(type: Test) {  
    include '**/integration/**'
}

При сборке ПО будет достаточно запусть простой набор команд gradle clean build deploy integrationTest, чтобы проверить, что ничего не сломалось и работает должным образом. Без каких-либо внешних программ.

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

comments powered by Disqus