Додавання одиничних тестів до старого простого проекту C

У заголовку все сказано. Моя компанія повторно використовує застарілий проект мікропрограмного забезпечення для пристрою мікроконтролера, написаного повністю на простому С.

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

Узагальнити:

• Як ви додаєте тестові одиниці до існуючого щільно зв'язаного коду перед рефакторингом?
• Які інструменти ви рекомендуєте? (менш важливо, але все одно приємно знати)

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

Візьміть копію « Ефективна робота зі спадковим кодексом » Майкла Пір’я. Мається на увазі впоратися з такими ситуаціями. Незважаючи на те, що він більше орієнтований на мови OO, такі як C ++ та Java, я вважаю, що він все ще може вам дуже допомогти.

Схоже, що частина його статті (або статтю раннього проекту) доступна навіть безкоштовно тут .

Щодо техніки, можливо, книга Майкла Пір'я у відповіді Петера Тьорека буде досить вичерпною. Якщо ви не хочете йти до книги, я пропоную тришаговий процес:

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

Повторіть цей процес кілька разів, і ви повинні виявити, що якість застарілої кодової бази значно зросла.

Що стосується інструментів, зауважте, що C ++ може зателефонувати в C, тому будь-яка рамка тестування одиниць C ++ може бути використана для тестування коду С. Наприклад, ми використовуємо CPPUnit для тестування купою коду С у нашому проекті.