Команді для початкового тестування команді для початківців потрібно провести одиничне тестування

Я працюю з новою командою, яка за минулий час не робила БЕЗПЕКИ тестування. Моя мета - це команда врешті-решт використовувати TDD (Test Driven Development) як свій природний процес. Але оскільки TDD - це така радикальна зміна розуму для невіддільної команди тестування, я подумав, що я просто розпочну з написання одиничних тестів після кодування.

Хтось був у подібній ситуації? Що є ефективним способом змусити команду бути зручною з TDD, коли вони не провели тестування? Чи має сенс це робити за кілька кроків? Або ми повинні зануритися прямо і зіткнутися з усіма зростаючими болями відразу ??

EDIT

Тільки для уточнення, в команді (крім мене самого) немає жодного, хто має будь-яке тестування експозиції / досвіду. І ми плануємо використовувати функціональність модульного тестування, вбудованого у Visual Studio.

Практикуйте за наявними помилками / дефектами.

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

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

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

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

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

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

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

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

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

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

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

6. До цього моменту команда вже повинна розуміти та сприймати TDD, і спадкові речі (не TDD) слід вважати важкими та дратівливими для роботи. Повторіть його: більшість поплів зроблять це із задоволенням.

Деякі інші важливі моменти:

• Переконайтеся, що ви використовуєте найкращі доступні рамки тестування. Буде набагато важче переконати людей робити TDD, якщо їм доведеться взаємодіяти з бібліотекою, яка погано написана.

• Переконайтеся, що тести легко запускаються і не потрібно багато часу, щоб закінчити (або обдурити, наприклад, використовуючи db-пам'ять для тестів).

• Налаштуйте кілька програмного забезпечення безперервної інтеграції, щоб негайно виявити зламані тести.

Один із способів отримати комфорт із TDD - це спочатку написати інтеграційні тести. Пізніше введіть тестові шви та справжні випробування.

Проблема написання одиничних тестів після кодування полягає в тому, що код не обов'язково має бути добре розроблений для перевірки . Можливо, вам знадобиться зробити деякий рефакторинг або, можливо, переробити дизайн для введення тестових швів. Але як можна безпечно переробляти або переробляти дизайн, якщо у вас немає жодного випробувального покриття ?

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

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

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

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

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

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

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

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