Як писати одиничні тести для роботів (та інших механічних пристроїв)?

Я є членом клубу робототехніки моєї середньої школи і відповідаю за програмування робота. Одна з пропозицій, яку я постійно чую від різних дорослих, - це те, що я повинен писати одиничні тести, щоб допомогти перевірити свій код. База коду стає трохи великою, і я погоджуюся, що одиничні тести були б дуже корисними, щоб допомогти мені швидше ловити помилки.

Однак я не зовсім впевнений, як я міг це досягти. Наскільки мені відомо, одиничне тестування проводиться шляхом взяття функції (або підсистеми коду) і подачі набір вхідних даних, щоб переконатися, що вона виходить з однаковим результатом кожного разу. Код, який у мене зараз немає, не робить суттєвих оброблень даних, а навпаки, безпосередньо маніпулює апаратними компонентами робота. Більшість складностей полягає в тому, щоб переконатися, що електроніка справна, що код на даний момент відповідає фактичному апаратному забезпеченню робота і т. Д. Часто часом я можу бачити лише наявність проблеми, завантажуючи код на самого робота, і намагання запустити його.

Як розширення, як можна записати одиничні тести для коду, призначеного для роботи будь-якого механічного пристрою? Мені здається, ви можете вловлювати помилки лише фізично спостерігаючи за роботою машини.

Або я просто не розумію, як повинні працювати одиничні тести?

( Якщо це має значення, ось код , він написаний на C ++, і я беру участь у FRC )

Вам потрібно буде знущатися над апаратним шаром, щоб зробити це тестування. Ідея полягає в тому, що замість того, щоб ваш код розмовляв із фактичним обладнанням, ви розмовляєте з підробленою версією обладнання, яким ви можете керувати, а потім використовуєте для перевірки правильності роботи вашого коду.

На жаль, є деякі проблеми, які вам доведеться подолати:

• Знущатися над речами на мовах порівняно низького рівня складніше (і, таким чином, набагато більше роботи)
• Знущатися з обладнання на рівні апаратних засобів складніше (і, таким чином, набагато більше роботи)

Крім того, більшість цінностей автоматизованого тестування блоків відбувається в тому, що ви можете в будь-який час запускати свої тести, щоб виявити помилки регресії протягом тривалого періоду часу після написання оригінального коду. З такими видами змагань ваш код взагалі не буде використовуватися після закінчення змагань, тому ви не отримаєте більшу частину вартості тестів. А враховуючи, наскільки складно буде додати тести до вашого конкретного випадку, можливо, краще використовувати свій час, щоб просто зробити ручне тестування та зосередитись на особливостях конкурсу.

Я можу придумати кілька речей, які вам потрібно буде розглянути. Перший - зробити ваш апаратний шар доступу максимально тонким, навіть якщо це означає створення базового шару типу обгортки для нього. Це пропонує вам кілька переваг. Перший полягає в тому, що він дозволяє ізолювати поведінку вашого коду, що залежить від обладнання, від самого апаратного доступу, а це означає, що ви можете протестувати все до самого дна апаратних пристроїв, не потребуючи доступу до самого обладнання.

Наприклад, якщо вам потрібно розробити протокол сигналізації на основі I2C, ви можете перевірити, чи ваш код генерує правильні сигнали I2C, не потребуючи підключення обладнання до ваших тестів.

Для дзвінків до власного обладнання ви можете перевірити, чи правильно вони поводяться, знущаючись над вашим апаратним шаром, і саме тут збереження дуже тонкого апаратного рівня справді окупається, оскільки ви можете звести макет до необхідності лише обробляти мінімальні функції, необхідні для насправді звертайтесь до обладнання, але вам не обов’язково потрібно перевіряти окремі сигнали, оскільки вся ваша сигналізація повинна була перевірятися на більш високому рівні. Це означає, що ви використовуєте макет, щоб перевірити, чи проводяться дзвінки до конкретних апаратних методів, які призводять до того, що ваші сигнали надсилаються на обладнання. Якщо вам потрібно опитати обладнання, тоді ваш макет повинен мати можливість викликати події або методи лише у вашому коді, оскільки знову ж таки, ваша зворотна сигналізація повинна оброблятися на більш високому рівні.

Це, в основному, відповідає тому, що Олексі сказав у своїй відповіді , в тому, що над знущанням над рівнем апаратного рівня зазвичай більше роботи, однак це не так вже й складно, якщо ви дотримуєтесь найменшого можливого шару мінімального коду / виклику, який ви можете зробити для обладнання.

Коли у вас є код, який проходить усі його тести, вам все одно доведеться пройти ряд ручних тестів, щоб бути впевненим, що ви все правильно налаштували на своєму апаратному рівні.

Інша річ, яка спадає на думку окрім глузування та шаруватості, - це використовувати тест-першу практику розробки. По суті, ви кодуєте свої вимоги як критерії тестування, і ви базуєте свою реалізацію на тестах. Це допоможе вам забезпечити зведення коду реалізації до мінімуму, а при цьому всі ваші тестові випадки керуватимуть вашими зусиллями з розробки. Не витрачаючи занадто багато часу на інший потенційно некритичний код, який, можливо, вам спокуситься зробити "просто тому", тест спочатку допомагає вам залишатися зосередженим, і вам буде легше змінити код під час налагодження, як і використання ваших одиниць тестів і знущань. Налагодження програмних помилок через апаратне забезпечення є надзвичайно складним і витягує велику кількість вашого часу, який ви вважаєте за краще витратити на інші завдання.

Я можу вам сказати, як це роблять на тренажерах польоту

По-перше, ви отримаєте лише половину відповіді, якщо ви задасте це питання лише програмістам, тому, ймовірно, вам слід переписати це на http://electronics.stackexchange.com, поки ви на це.

Я не робив жодної роботи з роботами, але я витратив 5 років, роблячи обладнання на тренажерах польотів, щоб я міг розповісти, як працює їх архітектура.

Апаратний шар тупий

Він містить базовий інтерфейс, де ви можете налаштувати прості значення введення / виводу та встановити інтерполяційні точки проходу для аналогових сигналів. Коли ви працюєте зі «свіжим» обладнанням, все буде працювати так, як очікувалося, з незначною калібруванням або взагалі без його калібрування, але з часом деталі зазнають механічного зносу і потребують коригування.

Калібрування - це проста таблиця, яка містить переріз між значеннями min / max. Для вимірювання вхідного сигналу зазвичай використовується сервопривод (наприклад, лінійний потенціометр, перетворювач, акселерометри тощо). Або, що стосується приладів, ви просто візуально оцінюєте точність і регулюєте, доки не відкалібруєте.

Програмний шар - навпаки

Все складно і взаємопов’язано, тому для перевірки функціональності важливо виділити деякі змінні. Не потрібно задавати собі головний біль, придумуючи сценарії, оскільки набагато простіше запустити реалістичні сценарії, де можна збирати дані. Під час запуску тестів ви в основному вимірюєте збережені дані по поточному виводу.

На польотному тренажері це називається QTG (Керівництво з кваліфікаційного тесту). По своїй суті він розміщує дані на 2D-сітці, де один вимір - це час, а другий - результат.

Вірите чи ні, це суть того, як вони розробляють моделі. Справжній літак оснащений тоною датчиків і пролітає навколо, роблячи керовані сценарії. Оскільки всі елементи керування можна керувати без взаємодії з людьми, тести виконуються (тобто сим летить) комп'ютером, і дані порівнюються.

Навіть незважаючи на те, що робототехніка створена в різному масштабі, принципи однакові. Традиційний підхід полягає в тому, щоб повністю розрізати апаратні та програмні шари, тому обидва можна перевірити індивідуально. Апаратне введення збирається через сервоприводи та встановлюється через незалежний інтерфейс. Вхід програмного забезпечення можна встановити / зчитувати, незалежно вимірюючи та порівнюючи сигналізацію, яка в іншому випадку переходитиме до обладнання та будує його на основі відомих «хороших» даних.

Самі тести не обов'язково повинні бути складними, якщо результати передбачувані, вимірювані та відтворювані.

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