Не дозволите да се тестни код увуче у производњу  ТЛ;ДР: Избегавајте додавање   или сличних заставица. исТестинг  Проблеми 😔  Пропуштена апстракција  Загађење не-пословног кода  Фрагиле Цоде  Недоследно понашање  Скривене зависности  Тешко отклањање грешака   Боолеан флагс  Непоуздани тестови   Код зависан од производње  Решења 😃  Уклони  понашање Ифс  Користите ињекцију зависности  Моделирајте екстерне услуге (немојте им   ) се ругати  Одвојене конфигурације  Изолујте логику теста  Одржавајте чисте границе понашања  Рефакторинг ⚙   хттпс://хацкерноон.цом/рефацторинг-014-хов-то-ремове-иф?ембедабле=труе  Контекст 💬  Када додате заставице као што   , мешате тестирање и производни код. је исТестинг  Ово ствара скривене путање које су активне само у тестовима.  Такође, не покривате прави производни код.  Ризикујете да испоручите понашање тестирања у производњу, што ће довести до грешака и непредвидивог понашања.  Пример кода 📖  Погрешно ❌   struct PaymentService { is_testing: bool, } impl PaymentService { fn process_payment(&self, amount: f64) { if self.is_testing { println!("Testing mode: Skipping real payment"); return; } println!("Processing payment of ${}", amount); } }  Тачно 👉   trait PaymentProcessor { fn process(&self, amount: f64); } struct RealPaymentProcessor; impl PaymentProcessor for RealPaymentProcessor { fn process(&self, amount: f64) { println!("Processing payment of ${}", amount); } } struct TestingPaymentProcessor; impl PaymentProcessor for TestingPaymentProcessor { // Notice this is not a mock fn process(&self, _: f64) { println!("No payment: Skipping real transaction"); } } struct PaymentService<T: PaymentProcessor> { processor: T, } impl<T: PaymentProcessor> PaymentService<T> { fn process_payment(&self, amount: f64) { self.processor.process(amount); } }  Детецтион 🔍    Полуаутоматски [к]  Овај мирис можете открити тражењем условних заставица као што су   ,   ,   и идиоми попут ових. исТестинг окружење == 'тест' ДЕБУГ_МОДЕ  Ово указује на то да понашање тестирања цури у производни код.  Ознаке 🏷  Тестирање  Ниво 🔋    Средњи [к]  Зашто је бијекција важна 🗺  Потребно вам је јасно раздвајање између тестног и производног кода.  Када их помешате, прекидате   један на један између понашања у стварном свету и програма. везу  Пошто су окружења ентитети из стварног света, потребно је да их експлицитно моделујете у   . МАППЕР-у  АИ генерација 🤖  Код генерисан од вештачке интелигенције често уводи овај мирис када користите брзе хакове за тестирање.  Неки алати предлажу заставице као што је   јер дају предност лакоћи у односу на правилан дизајн. исТестинг  АИ детекција 🥃  АИ алати могу ухватити овај мирис ако их конфигуришете да означавају условну логику на основу стања тестирања.  Пробајте их! 🛠   Запамтите: АИ асистенти праве много грешака  Предложени упит: Уклоните метод ИсТестинг и замените га моделирањем окружења  Без одговарајућих упутстава  Са посебним упутствима   ЦхатГПТ   ЦхатГПТ   Цлауде   Цлауде   збуњеност   збуњеност   Цопилот   Цопилот   Близанци   Близанци   ДеепСеек   ДеепСеек   Мета АИ   Мета АИ   Квен   Квен  Закључак 🏁  Избегавајте коришћење   заставица. исТестинг  Користите ињекцију зависности и моделирајте окружења да бисте држали логику тестирања и производње одвојене.  Односи 👩‍❤‍💋‍👨   хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-ккии   хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-киии   хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-ви-цмј31ом   хттпс://хацкерноон.цом/цоде-смелл-242-зомбие-феатуре-флагс?ембедабле=труе  Одрицање одговорности 📘  Код Мириси су моје   . мишљење  Цредитс 🙏  Фотографија   на  Цхристиана Гертенбацха Унспласх-у  Када додате заставице за тестирање, поткопавате поверење у производњу.   Вард Цуннингхам   хттпс://хацкерноон.цом/400-тхоугхт-провокинг-софтваре-енгинееринг-куотес?ембедабле=труе  Овај чланак је део ЦодеСмелл серије.   хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-и-ккз3евд?ембедабле=труе

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Овај аудио је произведен на оригиналном језику приче!

Предуго; Читати

Make resilience your competitive advantage

Шифра мириса 293 – Треба да избегавате додавање исТестинг или сличних заставица

Шифра мириса 293 – Треба да избегавате додавање исТестинг или сличних заставица

About Author

КОМЕНТАРИ

ХАНГ ТАГС

ОВАЈ ЧЛАНАК ЈЕ ПРЕДСТАВЉЕН У

Related Stories

Leadership Success Story: Srinath Muralinathan's Transformative Projects at Amazon

Building the Cloud Future: Sreedevi Velagala's Trek in AWS Architecture

Building a website with React and Bulma

Sravana Kumar Reddy Yeruva’s Fusion Transformation Sets a New Standard in ERP Excellence

Leadership Success Story: Srinath Muralinathan's Transformative Projects at Amazon

Building the Cloud Future: Sreedevi Velagala's Trek in AWS Architecture

Building a website with React and Bulma

Sravana Kumar Reddy Yeruva’s Fusion Transformation Sets a New Standard in ERP Excellence

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps