Nie pozwól, aby kod testowy przedostał się do produkcji  W skrócie: Unikaj dodawania flag   i podobnych. isTesting  Problemy 😔  Nieszczelna abstrakcja  Zanieczyszczenie kodu niebiznesowego  Kruchy kod  Niespójne zachowanie  Ukryte zależności  Trudne debugowanie   Flagi boolowskie  Niewiarygodne testy   Kod zależny od produkcji  Rozwiązania 😃  Usuń  zachowanie Ifs  Użyj wstrzykiwania zależności  Modeluj usługi zewnętrzne (nie   ich) wyśmiewaj  Oddzielne konfiguracje  Wyizoluj logikę testu  Utrzymuj czyste granice zachowania  Refaktoryzacja ⚙️   https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true  Kontekst 💬  Gdy dodajesz flagi takie jak   , mieszasz kod testowy i produkcyjny. isTesting  Tworzy to ukryte ścieżki, które są aktywne tylko w testach.  Ponadto nie omawiasz prawdziwego kodu produkcyjnego.  Istnieje ryzyko przeniesienia zachowań testowych do produkcji, co może prowadzić do błędów i nieprzewidywalnego zachowania.  Przykładowy kod 📖  Nieprawda ❌   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); } }  Dobrze 👉   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); } }  Wykrywanie 🔍    Półautomatyczny [x]  Możesz wykryć ten zapach, sprawdzając flagi warunkowe, takie jak   ,   ,   i podobne idiomy. isTesting environment == 'test' DEBUG_MODE  Oznacza to, że zachowanie testowe przedostaje się do kodu produkcyjnego.  Tagi 🏷️  Testowanie  Poziom 🔋    Średnio zaawansowany [x]  Dlaczego bijekcja jest ważna 🗺️  Konieczne jest wyraźne oddzielenie kodu testowego od kodu produkcyjnego.  Gdy je wymieszasz, rozbijasz   jeden do jednego między zachowaniem w świecie rzeczywistym a programem. bijekcję  Ponieważ środowiska są bytami świata rzeczywistego, należy je jawnie modelować w   . MAPPER  Generacja AI 🤖  Kod generowany przez sztuczną inteligencję często wprowadza ten problem, gdy do testowania stosuje się szybkie sztuczki.  Niektóre narzędzia sugerują flagi takie jak   , ponieważ priorytetowo traktują łatwość obsługi, a nie poprawny projekt. isTesting  Wykrywanie AI 🥃  Narzędzia AI mogą wykryć ten problem, jeśli skonfigurujesz je tak, aby sygnalizowały logikę warunkową na podstawie stanów testowych.  Wypróbuj je! 🛠   Pamiętaj: asystenci AI popełniają wiele błędów  Sugerowany monit: Usuń metodę IsTesting i zastąp ją modelowaniem środowisk  Bez odpowiednich instrukcji  Ze szczegółowymi instrukcjami   CzatGPT   CzatGPT   Klaudiusz   Klaudiusz   Zakłopotanie   Zakłopotanie   Drugi pilot   Drugi pilot   Bliźnięta   Bliźnięta   Głębokie poszukiwanie   Głębokie poszukiwanie   Meta-AI   Meta-AI   Qwen   Qwen  Wniosek 🏁  Unikaj stosowania flag   . isTesting  Użyj wstrzykiwania zależności i modeluj środowiska, aby oddzielić logikę testowania od logiki produkcji.  Relacje 👩‍❤️‍💋‍👨   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om   https://hackernoon.com/code-smell-242-zombie-feature-flags?embedable=true  Zastrzeżenie 📘  Zapachy kodów to moja   . opinia  Podziękowania 🙏  Zdjęcie autorstwa   na  Christiana Gertenbacha Unsplash  Dodając flagi testowe podważasz zaufanie do środowiska produkcyjnego.   Ward Cunningham   https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true  Niniejszy artykuł jest częścią serii CodeSmell.   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

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

Ten dźwięk jest produkowany w oryginalnym języku historii!

Za długo; Czytać

Make resilience your competitive advantage

Kod Smell 293 - Należy unikać dodawania flag isTesting lub podobnych

Kod Smell 293 - Należy unikać dodawania flag isTesting lub podobnych

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

Verified Writers

HackerNoon - A User Experience Analysis: Part 1

Pleasures of the telescope by Garrett Putman Serviss - Table of Links

The Blockchain Social Experiment: Enforced Logic

Verified Writers

HackerNoon - A User Experience Analysis: Part 1

Pleasures of the telescope by Garrett Putman Serviss - Table of Links

The Blockchain Social Experiment: Enforced Logic

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps