Ево како тестира екстерне АПИ-је у еликсиру помоћу обилазнице

Приоритетни смо принципи архитектуре оријентисане према услузи на Инверсе. То значи да имамо мале, одрживе компоненте са јасно дефинисаним одговорностима. Они комуницирају једни с другима (углавном), путем представничког трансфера државе, или РЕСТ, АПИ-ја.

Ово обезбеђује флексибилност и добро нам служи уз изузетак једног значајног аспекта: Тестирање. Приликом тестирања треба избегавати:

• Зависност од спољних сервиса који раде на истој машини.
• Спори тестови.

Пошто се апликације инхерентно ослањају на екстерне услуге, од кључног је значаја да постоји стратегија тестирања за те зависности.

Недавно смо почели да користимо Бипасс и објаснићу како смо стигли тамо и конкретно како га користимо.

Прошлост

Моцк методе и враћање неких примера података као што је овај:

То је био (и вјерујем да је још увијек) “пут до“ у свијету Руби / Раилс-а. Нажалост, то негативно утиче на лоше понашање које најбоље објашњава Јосе Валим.

Затим смо почели да користимо ЕкВЦР, који је велика библиотека, али има сличне недостатке као и моцк / стубс: подстиче лењост и не подстиче раздвајање питања која су критична за добро дефинисане АПИ-је. ЕкВЦР омогућава снимање и репродукцију реал-ливе података. Веома је лако интегрисати се (укључујући неколико редова у тесту и за све остало се брине). Али у идеалном случају морате размишљати о вањским зависностима у тестовима, а не их издвајати. Можда је то још увек поуздан избор за сценарије када би понашање крајње тачке требало тестирати са минималним оптерећењем (ми га користимо за тестирање позива на Амазонове АВС сервисе као што је С3).

Ентер Адаптерс

Адаптери раде одлично и промовишу промишљање око АПИ уговора и јасно дефинисаних граница комуникације. Још увек користимо овај приступ, посебно када је Адаптер комплекснији (као ЈСОН-РПЦ соцкет).

Овако изгледа адаптер:

Али за једноставне ХТТП Ендпоинтс, Адаптери изгледају као пуно посла и имају велики недостатак: они остављају библиотеке које конзумирају из једначине тестирања. Ако се нешто промени у ХТТП или ЈСОН библиотекама, тестови га неће ухватити. Количина критичног продукцијског кода који није тестиран овим приступом је неприхватљива.

Садашњост и будућност

Бипасс нам омогућава да покренемо веома једноставан веб сервер у тестовима који симулирају екстерне услуге које користимо.

Сада можемо да тестирамо цео стацк, укључујући ХТТП библиотеку, ЈСОН библиотеку за кодирање / декодирање и механизме за аутентификацију. Обилазница РЕАДМЕ је добро написана, тако да ћу поштедети детаље имплементације. Међутим, ми незнатно мијењамо начин на који га користимо како би тестови били сажети и читљиви:

Прво, понекад желимо да позовемо Фацебоок када се тестови изводе као комплетна интеграциона група. Ми то радимо нередовно како бисмо осигурали да Фацебоок АПИ и даље функционише према нашим очекивањима. Додавање - укључити интеграцију до мик тест не симулира АПИ, већ умјесто тога позива вањски сервис (линије 5, 7).

Ми смо експлицитни када симулирамо захтеве за екстерне сервисе тако да сваки тест који користи Бипасс мора имати @таг фацебоок_бипасс (ред 7).

Коначно, хандле_фб функција (линије 30–39) се зове (с обзиром да је рекуест_патх утакмице). Волим упаривање у функцијској глави јер она експлицитно прави пут на који реагујемо и омогућава нам да дефинишемо различите функције за различите путање.

Према томе, заобилажење ради само на тестовима означеним са @таг: бипасс и када не водимо интеграциони пакет. Још једна ствар коју радимо приликом подешавања Бипасса је да дозволимо тагу да проследи ид странице (линије 8, 20). Ево како тест који користи Бипасс изгледа у свој његовој величини:

Као што видите фацебоок_бипасс таг чини експлицитним да симулирамо АПИ (осим ако смо у режиму интеграције). То нам омогућава да проследимо информације симулираном АПИ-ју, и врло је лако поново користити исти Бипасс конфигурацију за различите тестове.

Надам се да ће вам ово помоћи да тестирате спољне АПИ-је. Можете ме наћи на Твиттеру (види доле) ако имате додатних питања.