Przypomniało mi się to powiedzenie o tym, że nie martwię się o drzwi stodoły, kiedy koń już pędzi.
Rzeczywistość jest taka, że naprawdę nie ma opłacalnego sposobu na uzyskanie dobrego pokrycia testowego dla starszego systemu, z pewnością nie w krótkim czasie. Jak wspomniał MattNz, będzie to bardzo czasochłonny proces, a ostatecznie wyjątkowo kosztowny. Moja intuicja mówi mi, że jeśli spróbujesz zrobić coś, aby zrobić wrażenie na zarządzaniu, prawdopodobnie stworzysz nowy koszmar konserwacji, ponieważ próbujesz zbyt szybko pokazywać zbyt wiele, bez pełnego zrozumienia wymagań, które próbujesz przetestować.
Realistycznie, po napisaniu kodu, jest już prawie za późno, aby napisać testy skutecznie bez ryzyka pominięcia czegoś istotnego. Z drugiej strony można powiedzieć, że niektóre testy są lepsze niż brak testów, ale w takim przypadku same testy muszą wykazać, że wnoszą wartość dodaną do systemu jako całości.
Moją sugestią byłoby przyjrzenie się kluczowym obszarom, w których czujesz, że coś jest „zepsute”. Rozumiem przez to, że może to być bardzo nieefektywny kod lub że można wykazać, że jego utrzymanie było wcześniej kosztowne. Udokumentuj problemy, a następnie wykorzystaj to jako punkt wyjścia do wprowadzenia poziomu testowania, który pomoże Ci ulepszyć system, bez podejmowania ogromnych wysiłków związanych z przeprojektowaniem. Chodzi tutaj o to, aby uniknąć nadrabiania zaległości w testach, a zamiast tego wprowadzić testy, które pomogą Ci rozwiązać określone problemy. Po pewnym czasie sprawdź, czy możesz zmierzyć i rozróżnić poprzedni koszt utrzymania tej sekcji kodu oraz bieżące wysiłki związane z poprawkami, które zastosowałeś w ich testach pomocniczych.
Należy pamiętać, że kierownictwo jest bardziej zainteresowane kosztem / korzyściami i tym, jak bezpośrednio wpływa to na ich klientów, a ostatecznie na ich budżet. Nigdy nie są zainteresowani robieniem czegoś po prostu dlatego, że jest to najlepsza rzecz, chyba że możesz udowodnić, że zapewni im to interesującą ich korzyść. Jeśli jesteś w stanie wykazać, że poprawiasz system i otrzymujesz dobre pokrycie testowe dla pracy, którą obecnie wykonujesz, kierownictwo jest bardziej skłonne postrzegać to jako skuteczne zastosowanie twoich wysiłków. Może to pozwolić ci na argumentowanie za rozszerzeniem swoich wysiłków na inne kluczowe obszary, bez wymagania albo całkowitego wstrzymania rozwoju produktu, albo, co gorsza, prawie niemożliwego do argumentowania za przepisaniem!