Nie pozwól, aby kod testowy przedostał się do produkcji

W skrócie: Unikaj dodawania flag isTesting i podobnych.

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 😃

1. Usuń zachowanie Ifs
2. Użyj wstrzykiwania zależności
3. Modeluj usługi zewnętrzne (nie wyśmiewaj ich)
4. Oddzielne konfiguracje
5. Wyizoluj logikę testu
6. Utrzymuj czyste granice zachowania

Refaktoryzacja ⚙️

Kontekst 💬

Gdy dodajesz flagi takie jak isTesting , mieszasz kod testowy i produkcyjny.

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 🔍

• [x] Półautomatyczny

Możesz wykryć ten zapach, sprawdzając flagi warunkowe, takie jak isTesting , environment == 'test' , DEBUG_MODE i podobne idiomy.

Oznacza to, że zachowanie testowe przedostaje się do kodu produkcyjnego.

Tagi 🏷️

• Testowanie

Poziom 🔋

• [x] Średnio zaawansowany

Dlaczego bijekcja jest ważna 🗺️

Konieczne jest wyraźne oddzielenie kodu testowego od kodu produkcyjnego.

Gdy je wymieszasz, rozbijasz bijekcję jeden do jednego między zachowaniem w świecie rzeczywistym a programem.

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 isTesting , ponieważ priorytetowo traktują łatwość obsługi, a nie poprawny projekt.

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

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

Zastrzeżenie 📘

Zapachy kodów to moja opinia .

Podziękowania 🙏

Zdjęcie autorstwa Christiana Gertenbacha na Unsplash

Dodając flagi testowe podważasz zaufanie do środowiska produkcyjnego.

Ward Cunningham

Niniejszy artykuł jest częścią serii CodeSmell.