Синхронізуємо тестові дані за допомогою костилів (Google Script)

Привіт, друзі! Уявіть ситуацію: треба покрити автоматизованими тестами деяку функціональність, що приймає в якості вхідних даних унікальні одноразові коди.

Очевидна проблема: як змусити автотести стабільно працювати, якщо код дійсно унікальний і одноразовий? Я одразу ж продумав кілька можливих рішень (які б мінімізували особисто мою роботу 😅) і запропонував їх замовнику на вибір:

• створити тестовий набір кодів, що можна перевикористати (не змінюють статус в базі після використання) —> нажаль ні, розробники не мають наразі і в запланованому майбутньому можливості такі зробити;
• створити вебсервіс у тестовому середовищі, що дав би мені можливість додавати свої коди чи робити знов активними використані —> теж ні, з тої ж причини;
• додати можливість обходити перевірку коду для розблокування подальшого функціоналу —> теж ні, з тої ж причини. І взагалі, моя задача — зробити тестування продукту, максимально схожого на Production, а не бекдори пропонувати;
• доступ до бази я просив ще раніше —> теж ні. Вона ж десь там, на хмаринці, а я тут, просто в Києві ¯\_(ツ)_/¯

Єдине, що мені запропонували — «давай ми тобі згенеруємо кілька тисяч кодів, а ти вже придумай, що з ними робити. Буде мало — тільки скажи. Спеціально навчена людина згенерує тобі ще»

Тож я став думати, як мені ті коди правильно використати — жодної БД нема, з файлу читати — така собі ідея, адже ці тести я і команда запускаємо локально для дебагу та розробки, а ще CI pipeline щодня по кілька разів.

І я придумав костиль, який мені не дуже подобається, але вирішує задачу з мінімальними проблемами. Я використав Google Script, щоб написати сервіс, що на кожен запит буде видавати унікальний код купону — а далі лишень треба його викликати з коду тесту (скоріше фікстури, але це вже деталі). Ідея проста:

1. Всі не використані коди розміщуються в Google Spreadsheet фалі
2. Пишеться та публікується Google Script, що на кожен POST запит має відповідати кодом і видаляти його з таблиці
3. В тестовому проєкті додається виклик рест сервісу, що забирає код
4. PROFIT (до речі, часто використовую цю відсилку — хтось взагалі знає, на що вона чи тільки я такий старий?)

Код написав та протестував за 30 хв:

const sheetId = '';


function doGet(e) {
  return ContentService.createTextOutput('I am alive')
}

function doPost(e) {
  try {
    let content = JSON.parse(e.postData.contents);
    if (content.uuid == '') {
      let code = getNextCode();
      return ContentService.createTextOutput(code);
    } else {
      return ContentService.createTextOutput('bad uuid');
    }
  } catch (e) {
    return ContentService.createTextOutput('error');
  }
}

function getNextCode() {
  let file = SpreadsheetApp.openById(sheetId);
  let sheet = file.getSheets()[0];
  let code = sheet.getRange('A' + 1).getValue().toString();
  sheet.deleteRow(1);
  if (code.length == 0) {
    return 'empty'
  }
  return code;
}

function test(){
  Logger.log(getNextCode());
} 

Q: Чому не зробити видачу кодів за методом GET?

A: Не хотів випадково втрачати робочі коди, просто перевіряючи в браузері, що сервіс працює

Q: Нащо в коді перевірка на uuid?

A: Додатково міра безпеки — я порахував, що унікальна адреса веб сервісу та унікальний uuid гарантують мені мінімальний рівень безпеки, щоб хтось випадково не використав всі коди. Можна і без неї

Q: Що діється в функції getNextCode?

A: Дякую, що спитав! Відкриваю файл за його ID, беру значення першої клітинки першого стовпчика А (саме в першому стовпчику всі коди), видаляю всю строку з цим значенням та повертаю його

Q: Нащо повертати empty замість пустої строки по замовчуванню?

A: В мене були сумніви, чи завжди пусте строка означатиме, що кодів більше нема, а не просто збій сервісу. До того ж, в тестовому проєкті однаково робити перевірку.

Q: Що робить функція test?

A: Тестує! Перед заповненням файлу реальними кодами, протестував рішення, виконавши декілька разів функцію тест та перевіривши логи і зміст файлу

Власне, все, чим хотів поділитись. Якщо ви знаєте кращі рішення, киньте в мене коментом (просто впевнений, що має щось бути). Тим не менше, сподіваюсь, комусь пост буде корисним!

Дякую що дочитали. В самому кінці не можу не додати хвилинку самореклами — може, дехто з вас знає, я з колегами веду канал про тестування — t.me/qamania.

А нещодавно я опублікував цілий курс з автоматизації тестування інструментом playwright мовою python (до речі, свій костиль для синхронізації кодів я як раз написав для проєкту на playwright) — запрошую ознайомитись.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті