Кращі практики для модернізації застарілого коду за допомогою автоматизованих тестів

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

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

Перш за все, прочитайте та прочитайте « Ефективна робота зі спадковим кодексом Майкла Пір’я» - це незамінна допомога для таких завдань.

Потім кілька приміток:

• чи є у вас точна специфікація / контракт на інтерфейс, чи у вас практично тільки існуюча реалізація як "специфікація"? У першому випадку простіше зробити повне перезапис з нуля, в другому важко неможливо.
• якщо ви хочете повторно реалізувати інтерфейс, найкориснішим способом витратити свої тестові ресурси є написання тестів лише проти інтерфейсу. Звичайно, це не кваліфікується як одиничне тестування в строгому сенсі, скоріше функціональне / приймальне тестування, але я не є пуристом :-) Однак ці тести можуть бути повторно використані і дозволяють безпосередньо порівнювати результати двох реалізацій поряд .
• загалом, я б віддав перевагу рефакторингу існуючого коду, а не перезаписуванню з нуля, якщо це не є абсолютно неможливим. (Але в цьому випадку, як ви все-таки будете писати одиничні тести проти нього?) Перегляньте цю публікацію від Джоела для більш детального обговорення цього питання. Створивши набір тестів на прийняття інтерфейсу, ви отримуєте тонку, але корисну мережу безпеки, проти якої ви можете почати обережно переробляти існуючий код на те, щоб зробити його одиничним для перевірки (використовуючи ідеї з книги Пір'я).

Найкращим методом відомо, є метод Mikado. http://mikadomethod.wordpress.com/2010/08/04/the-mikado-method-book/ Це лише узагальнення простої методики, але це єдиний спосіб я знати, як почати покращувати якість коду у великій базі коду не приймаючи зайвих ризиків.

WEWLC також дуже хороша книга про це, але написання на C ++ не завжди корисно з кодом Java або Ruby.

Ретро тести на встановлення старої кодової бази можуть бути досить складними, якщо це монолітне оформлення.

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

Я хотів би додати одне посилання . Є кілька прикладів не настільки легко спробних реалізацій, які знову перетворюються на більш дружній код xUnit. Що стосується загального підходу, спробуйте вже згадувані посилання (Joel post, Work With Legacy code