Хто займається тестовими розробками?

Я працював у корпоративному просторі останні 4½ роки і зауважив, що в цілому підприємства не є сприятливим середовищем для тестового стилю розвитку. Зазвичай проекти мають фіксовану вартість, фіксовану шкалу часу та стиль водоспаду. Будь-яке тестування одиниць, якщо воно взагалі робиться, зазвичай відбувається після розробки на етапі QA та виконується іншою командою.

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

З якими типами магазинів, компаній та клієнтів найкраще працює тестова розробка? Які проекти, як правило, сприяють розвитку TDD?

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

Сьогодні мій бос нагодував мене гарним на цьому, я думаю, я збираюсь його вкрасти, як він його викрав у когось іншого.

"Чи очікуєте ви, щоб тесляр виміряв дошку, перш ніж він її обріже?"

Я брав клас по дереву в середній школі і займався будівництвом через школу. Наша мантра завжди була "міряти двічі, один раз вирізати", за якою слідував саркастичний "Я розрізав її і зрізав її ще раз, і вона все ще була занадто короткою!"

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

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

Ви можете перевірити код драйву навіть у проекті водоспаду, це інженерна дисципліна, а не техніка управління проектами.

Я жодним чином не фанатик TDD, але це дуже багато вчить про дизайн програмного забезпечення.

Візьміть з собою, оскільки це матиме виразний. Net аромат: с

Що стосується типів проектів, які піддаються тестовому підходу, то я би звернув увагу на деякі речі:

• Ви маєте справу з існуючою базою коду? Переоблаштовувати тестовий набір часто надмірно дорого. Отримайте уявлення про те, скільки існує успадкованого технічного боргу
• певні платформи і рамки є невід'ємними для тесту. Нещодавній досвід, який мені запам’ятався - SharePoint, наприклад, TDD дуже важко (але не неможливо). Такі речі, можливо, вам доведеться вдатися до комерційного ізолятора, такого як TypeMock.
• певні підходи до впровадження краще піддаються TDD, ніж інші. Наприклад, ASP.Net з кодовим відставанням - не настільки перевіряється. ASP.Net MVC - перевіряється. Silverlight з кодовими спинками - не настільки перевіряється. Silverlight з MVVM - перевіряється.

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

+1 про коментар mpenrow про те, що не повідомляти mgmt, якщо вони мають проблеми з цим: p

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

Ви також можете зробити хороші ділові справи:

• TDD можна просто узагальнити як "специфікацію, яку система може автоматично перевірити". Це не програмування інакше, це не побудова іншого продукту.

• Тестування одиниць - це лише форма автоматизованого тестування; що лише дозволяє комп’ютеру робити для себе те, що компанія, ймовірно, платить інженерам з космосу, щоб це робити вручну. Автоматизовані тести працюють швидше, послідовніше і, коли вони добре написані, - забезпечують швидкий, стислий і точний зворотний зв'язок, описи та напрямок до проблеми

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

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

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

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

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

Якщо ви поясните "Я пишу тести", тоді Сили, які є, можуть сказати "О, ми можемо це усунути!" Але якщо ви нікому не скажете, то ви все одно маєте тести як залишок процесу кодування.

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

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

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

• Не існує великої існуючої кодової бази до початку TDD

• Компанія не величезна, і тому не має великої кількості відкатів "ми завжди робили це по-іншому".

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

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

• Системи в непрообразованном стані. В ідеалі наступна велика версія після прототипу - де доведення концепції закінчено і проект фінансується, але всі знають, що наступна спроба має підскочити в якості.

• Зацікавлені сторони, які вкладаються в процес.

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

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

З огляду на те, що книги, такі як Марш смерті, вказують на поширене явище, тобто галузь, зазнала розвитку «руйнування» та «рубіж», я вважаю, що TDD, мабуть, є рідкісним стартапами або монолітними підприємствами, що добре фінансуються. Справа не в тому, що люди там не вірять у цінність TDD - але це занадто абстрактно, щоб продати своїм клієнтам.

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

Тож я думаю, що вам доведеться робити якісь LearningTests, окремі докази концепцій і переписувати їх згодом тощо, чи я помиляюся?

І (я знаю, що це старий, але я ще не побачив жодної хорошої відповіді): як ви кодуєте алгоритми, використовуючи TDD (коли результати можуть бути складними, щоб справді "затвердити" з легкістю)?

Я справді бачу позитивні сторони TDD і я на човні, але для початківців дуже важко, коли написаний вами код у вас вдвічі перевищує час (а у вас є однолітки, які зовсім не бачать плюсів і знущаються над вами з RAD)

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

Я роблю це. Хід наших історій користувачів відстежується на дошці Kanban, на якій є "Має тест?" стовпчик ліворуч (вгору за течією) розвитку.

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

Цикл зворотного зв'язку з прийняттям тестування виглядає досить довго: завершення історії може зайняти кілька днів. Розробка має власні, коротші петлі зворотного зв'язку TDD.

"[... немає тестового стилю ...] Більше схожий на Agile ...."

Це повне хибне представлення Agile. Визначення зробленого є ключовим компонентом Agile, і одним із стовпів, на якому він спирається, є автоматизоване тестування прийняття (те, що я описав вище, це один із способів зробити це). Якщо екстремальне програмування (XP) використовується як метод реалізації Agile, то ATDD / BDD і TDD призначаються.

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

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

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

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

У 11 років я займався професійним програмуванням, лише останні два організації навіть знали про TDD (це було майже 5 років, до цього часу TDD не був таким популярним, як сьогодні). Я вирішу погоню і відповім на ваше запитання, перш ніж перейти до мого торгового поля для TDD :)

В останній компанії, в якій я працював (он-лайн академічний видавець гуманітарних та наукових колекцій), ми знали, що нам потрібно практикувати TDD, але ми там ніколи не потрапляли. На захист у нас була база коду на 250 тис., Тому додавання тестів до нестабільної кодової бази такого розміру здавалося непереборним (я відчуваю провину, набравши це зараз!). Навіть найкращі з нас помиляються .

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

Ми тимчасово збільшили нашу команду з контролю якості (від одного, можливо, двох людей до півдесятка чи більше), щоб протестувати платформу перед будь-яким випуском. Це було надзвичайно дорого, мудро і фінансово, на деякі випуски знадобиться три місяці, щоб пройти «тестування». Вже тоді ми знали, що ми доставляємо проблеми, вони просто не були "блокаторами" або "критичними", а "високими пріоритетами".

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

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

Крок продажів ...

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

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

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

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

На мою думку, галузь розробки програмного забезпечення (в цілому) в даний час порушена, той факт, що наявність тестів для вашого програмного забезпечення НЕ є нормою.

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

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

Я б заперечував у вашому питанні ...

Зазвичай вони хотіли, щоб розробка почалася негайно, або після короткого дизайнерського рішення. Більш схожий на Agile.

Будучи "Agile" не передбачає проходження без тестів, першим учасником, переліченим на agilemanifesto.org, є Кент Бек , творець XP та TDD!

Дві книги, які я дуже рекомендую, якщо ви зацікавлені в TDD, або просто не прочитали їх і є захопленим програмістом (це всі читають правильно?;)

Вирощування об'єктно-орієнтованого програмного забезпечення, керованого тестами

Чистий код - серія Роберта К. Мартіна ("Дядько Боб")

Ці дві книги компліментують одна одній і конденсують багато сенсу на кілька сторінок.

Дякуємо, що задали це питання :)

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

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

• 73 000 рядків коду
• 91 378 600 рядків тестового коду

Дивіться http://www.sqlite.org/testing.html