Il CMS che stiamo sviluppando sta diventando davvero disordinato. Una delle parti mancanti è "unit test".
Per dirla in parole semplici: ciò che chiamiamo testing dell'unità in realtà è piuttosto vago, più vicino a test di integrazione e funzionalità, ma uno dei miei colleghi (che non è ufficialmente il nostro principale) non si preoccupa "attenersi alle definizioni": "i test che ho scritto funziona, tutto qui".
Tuttavia, i test sono abbastanza brutti. Praticamente il 90% del codice non può essere testato correttamente, per diversi motivi:
- hanno deciso (prima di rientrare) di utilizzare un "autoloader interno", chiamando un metodo oggetto per "importare" i moduli,
- la maggior parte degli oggetti ha bisogno del "contesto",
- accoppiamento pesante,
- violazioni della maggior parte dei "principi OOP",
- ecc.
Tutto questo finisce in:
- configurazioni gonfiabili / abbattimenti,
- test non deterministici
- perdite di stato,
- test di classe A improvvisamente falliti perché abbiamo modificato la classe B,
- ecc.
Certo, a volte è inevitabile che l'unità che testa alcune parti risulti essere complessa e non "ideale", ma dovrei continuare a considerare che non essere in grado di testare correttamente la maggior parte del codice sorgente è un strong odore di codice? Potrebbe essere una valida argomentazione per cercare di inserire la nostra base di codice in qualcosa di più pulito prima ancora di aggiungerci sopra?
Te lo chiedo, perché io vengo dal mondo PHP, dove ora tendiamo a scrivere un codice sempre più rigido, rigorosamente tipizzato, "SOLID aware" ... Non sono molto fiducioso nel discernere cosa c'è di veramente sbagliato, e cosa è relativo a Python (per merci o cattivo).