Розробка міжмовних тестів

Коротке запитання: як слідкувати за тестовою розробкою проекту, який охоплює кілька мов?

Зокрема, я пишу веб-додаток, що використовує JavaScript та PHP, і я хочу слідувати принципам TDD, але не знаю, як їх інтегрувати. Чи запускаю окремі тестові набори для розділів JS та PHP і використовую макети в наборі JS для імітації відповідей сервера? Чи існує методика одиничного тестування обох компонентів за один пробіг?

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

Я пишу свої тести на PHP в SimpleTest, а тести на JavaScript в JsTestDriver. Я звик до об'єктно-орієнтованих парадигм, тому у мене є кілька класів у PHP, і я роблю щось подібне в JavaScript, використовуючи прототипне успадкування. Я також почав читати цю книгу про TDD в Python і цю про TDD в JavaScript , але, з усього, що я бачив, вони не описують тестування програми в повному обсязі (за винятком використання чогось на зразок Selenium чи іншого веб-драйвера для того, щоб провести тестування приймання на передньому рівні. Чи просто TDD не вирізаний для розробників повних стеків?

Чи існує методика одиничного тестування обох компонентів за один пробіг?

Це насправді буде протилежним тестуванню одиниць - тестування одиниць, особливо в стилі TDD, означає перевірити свої компоненти ізольовано . Таким чином, відповідь "так ": запускайте окремі тестові набори для секцій JS та PHP ", інакше це не тестування модулів і не TDD.

Звичайно, тести автоматизованої інтеграції можуть протестувати "обидва компоненти за один цикл", і ви можете використовувати саме ті інструменти, про які ви вже згадували (наприклад, Selenium). Але це, як правило, більш складні тести, розроблені поза циклами TDD.

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

Ключовою частиною одиниць тестів є ізоляція досліджуваної одиниці від її залежностей. Це дає дві дуже важливі переваги:

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

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

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

Якщо, з іншого боку, ви хочете займатися ATDD, переконайтеся, що ви шукаєте ресурси для цього конкретно (це часто робиться як частина BDD, тому також подивіться на націлені на це інструменти). Ось де природно вміститься щось на кшталт Selenium. Зазвичай, виконуючи ATDD, ви все одно пишете одиничні тести, а для того, щоб пройти кожен тест прийняття, ви можете протестувати його реалізацію і з одиничними тестами. Тож навіть якщо ви хочете робити ATDD, розуміння того, як писати одиничні тести, все ще важливо.

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

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

Дядько Боб пояснює це так краще, ніж я. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html