Non lasciare che il codice di test si insinui nella produzione

TL;DR: Evita di aggiungere flag isTesting o simili.

Problemi 😔

• Astrazione che perde
• Inquinamento del codice non commerciale
• Codice fragile
• Comportamento incoerente
• Dipendenze nascoste
• Debug difficile
• Flag booleani
• Test non attendibili
• Codice dipendente dalla produzione

Soluzioni 😃

1. Rimuovi comportamento Se
2. Utilizzare l'iniezione di dipendenza
3. Modella i servizi esterni (non prenderli in giro )
4. Configurazioni separate
5. Logica di test isolata
6. Mantenere puliti i confini del comportamento

Rifattorizzatori ⚙️

Contesto 💬

Aggiungendo flag come isTesting , si mescolano codice di test e di produzione.

In questo modo si creano percorsi nascosti attivi solo nei test.

Inoltre, non viene trattato il vero codice di produzione.

Si rischia di trasferire il comportamento dei test alla produzione, causando bug e comportamenti imprevedibili.

Codice di esempio 📖

Sbagliato ❌

 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); } }

Giusto 👉

 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); } }

Rilevamento 🔍

• [x] Semi-automatico

È possibile rilevare questo odore cercando flag condizionali come isTesting , environment == 'test' , DEBUG_MODE e idiomi come questi.

Ciò indica che il comportamento dei test si sta infiltrando nel codice di produzione.

Etichette 🏷️

• Prova

Livello 🔋

• [x] Intermedio

Perché la biiezione è importante 🗺️

È necessaria una netta separazione tra codice di test e codice di produzione.

Quando li mescoli, interrompi la biiezione uno a uno tra il comportamento del mondo reale e il programma.

Poiché gli ambienti sono entità del mondo reale, è necessario modellarli in modo esplicito nel MAPPER .

Generazione AI 🤖

Il codice generato dall'intelligenza artificiale spesso introduce questo odore quando si utilizzano rapidi trucchi per i test.

Alcuni strumenti suggeriscono flag come isTesting perché danno priorità alla semplicità rispetto alla progettazione adeguata.

Rilevamento AI 🥃

Gli strumenti di intelligenza artificiale possono captare questo odore se vengono configurati in modo da contrassegnare la logica condizionale in base agli stati di test.

Provali! 🛠

Ricorda: gli assistenti AI commettono molti errori

Prompt suggerito: rimuovere il metodo IsTesting e sostituirlo modellando gli ambienti

Conclusione 🏁

Evitare di utilizzare i flag isTesting .

Utilizzare l'iniezione di dipendenza e modellare gli ambienti per mantenere separate la logica di test e quella di produzione.

Relazioni 👩‍❤️‍💋‍👨

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

Dichiarazione di non responsabilità 📘

Gli odori del codice sono la mia opinione .

Crediti 🙏

Foto di Christian Gertenbach su Unsplash

Aggiungendo flag di test, si compromette la fiducia nella produzione.

Reparto Cunningham

Questo articolo fa parte della serie CodeSmell.