Чи змушує мене тестова розробка дотримуватися SOLID?

15

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

Чи змушує TDD розробників слідувати SOLID активніше, ніж просто писати одиничні тести?

unit-testing tdd solid

— Сибірський гуй
джерело

1

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

— Ям Маркович

1

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

— Amit Wadhwa

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

— Ям Маркович

24

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

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

Якщо ви вже знаєте про принципи SOLID, TDD спонукає вас думати про них та активно їх використовувати.

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

Наприклад:

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

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

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

Найголовніше, що принципи SOLID були розроблені для того, щоб заохочувати писати більш чистий, зрозумілий і доступний код, і це було TDD. Тож якщо ви правильно зробите TDD, і ви звернете увагу на те, як виглядають ваш код та ваші тести (і це не так складно, оскільки ви отримуєте негайний зворотній зв'язок, API та правильність), ви можете менше турбуватися про принципи SOLID.

— Ям Маркович
джерело

Крім того, якщо ви не будете слідувати за відкритим / закритим та заміною Ліскова, ваші знущання згодом зламаються. Тож навіть якщо TDD може не допомогти вам застосувати OCP та LSP, створені тести дозволять вам знати, коли ви його порушите. Більше ефекту від тестування загалом, але все ж варто згадати.

— Йонас Шуберт Ерландссон

9

Ні

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

— дієтабудда
джерело

2

Моє розуміння принципів СОЛІД розширилося на порядок, коли я почав займатися TDD. Як тільки я почав думати про те, як знущатися над залежностями, я зрозумів, що практично кожен компонент у кодовій базі мав потенційну альтернативну реалізацію. І наскільки простіше тестувати простий публічний API.

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

— Хіт Ліллі
джерело

0

Так : TDD - це в основному хороша техніка проектування (і лише вторинна методика тестування). Це дуже допомагає досягти твердих принципів, хоча (патологічні) приклади TDD з великою кількістю кодових запахів все ще можливі.

Зв'язок між TDD та твердими принципами суперечить (із висновком вище) у цьому чудовому подкасті «hanselminute» під назвою «Розробка тестових програм - це дизайн - останнє слово на TDD» .

— DaveFar
джерело