Як розділити код тестової обробки зображень?

Я працюю в обробці зображень (в основному OCR) і мені цікаво, як я повинен інтегрувати одиничні тести у свою розробку.

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

Редагувати: Аналіз символу може пройти багато кроків, що включають багаторазові обертання, масштабування та морфологічні операції. Ці кроки часто змінюються в процесі розробки алгоритму. Таким чином, вхід і очікуваний вихід можуть значно розвиватися під час тестування. Кожен символ може бути 100x100 пікселів, тому жорстке кодування їх у коді або робота з генерованими даними не викликає сумнівів.

— rold2007
джерело

Чи можете ви накреслити приклад функції, коли у вас виникли проблеми зі створенням тесту на одиницю?

— Doc Brown

Занадто короткий для реальної відповіді, а не для тестування одиниць: ми обробляємо дані вручну (як у: проходить велика кількість вибірки - я зазвичай перевищую 1000 для таких завдань класифікації, але це залежить від вашого загального розміру вибірки ) та порівняння кінцевих результатів із обробленими вручну даними автоматично. Я створив невелику основу для цього, вона відкриється з відкритим кодом через кілька тижнів, але це опис - ви можете клонувати процес: birgitplays.wordpress.com/2012/09/15/…

— Birgit P.

Для вашого прикладу ви можете легко протестувати обертання, масштабування тощо як невеликі одиниці тестів. Поворот заданого зображення на 45 градусів не повинен сильно змінюватися. Це також стосується масштабування та морфологічних операцій. Проте протестувати те, де очікуваний результат розвивається під час впровадження, проте важко. Ви можете спробувати зробити міру якості та сказати якість> = деяка_якість. Щоб переконатися, що якість не погіршує, але це також може бути важким. Крім того, все, що ви можете зробити - це тести, які підтверджують, що основні деталі не порушені. Як масштаб / поворот / тощо.

— martiert

@martiert: Я не перевіряю обертання, масштабування тощо, як називаю їх з 3-ї бібліотеки, яку, на мою думку, добре перевірено. Алгоритм OCR складається з багатьох цих операцій. Але, як ви кажете, перевірити щось, де розвивається результат, важко. Можливо, це гарне попередження, що у нас немає вибору, але залежати від інтеграційних тестів ...

— rold2007

@Birgit P .: Цікаве рішення. Як ви кажете, це все-таки інтеграційне тестування. Наявність такої рамки, як ваша, допоможе швидше налаштувати ці тести, але вони не працюватимуть швидше ...

— rold2007

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

Збережіть вхідні / вихідні зображення як ресурси у проектному тестовому проекті. Потім слід перевірити одиничну перевірку того, що коли вводиться конкретний вхід, виробляється конкретний вихід.

У 9/10 разів, коли ви переробляєте код і додаєте інші функціональні можливості, ви очікуєте, що поведінка підпрограми обробки зображень не зміниться, тому, якщо всі раптові тести блоку почнуть виходити з ладу, це може бути пов’язано з помилкою.

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

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

— DXM
джерело

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

— Kemoda

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

— tdammers

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

— DXM

@DXM: Я розумію ваше рішення, але, думаю, ми можемо не мати однакових обмежень. Мої вхідні / вихідні дані сильно змінюються під час розробки алгоритму. Як ви справляєтесь із цими регулярними змінами? У OCR я можу мати понад 99% точності, тому тестування лише на декількох зображеннях може дати мені помилкове відчуття успіху, тоді як інтеграційні тести можуть сказати мені пізніше, що я фактично погіршив алгоритм ...

— rold2007