Tego rodzaju testy byłyby rzeczywiście lepsze. Rzecz w tym, że powinni to robić testerzy, a nie programiści . W tym sensie nie jest to ani praca twoich, ani twórców bibliotek.
Z tego, co opisujesz, wygląda na to, że w projekcie nie ma testerów - jeśli tak jest, to jest to problem zarządzania i dość poważny.
... oszczędza czas, ponieważ mogą odczytać kod źródłowy bibliotek w celu ustalenia, czy wymagana funkcjonalność jest dostępna
Dość kiepskie rozumowanie. Kiedy najnowsza wersja biblioteki nie może się skompilować z najnowszym projektem wersji, może to być wiele różnych przyczyn - po prostu wczytywanie kodu źródłowego lib może być stratą czasu.
- Co zrobić, jeśli biblioteka działa poprawnie, a błąd kompilacji został spowodowany błędem w kodzie projektu? Lub co jeśli niepowodzenie kompilacji zostało spowodowane tymczasową niezgodną zmianą, która powinna zostać poprawiona dzień lub dwa później? Co jeśli niepowodzenie kompilacji wskazuje na skomplikowany problem z integracją, który zajmie tydzień lub miesiąc? Czy w przypadku problemu z integracją korzystanie z biblioteki wcześniejszej wersji może to obejść?
Niezależnie od przyczyny, wstępna analiza awarii oznaczałaby marnowanie czasu programisty na pracę, która powinna zostać wykonana przez testerów.
Kolejną rzeczą nad brakami w rozumowaniu są nieuniknione (i dość bolesne z mojego doświadczenia) straty produktywności, które następują, gdy trzeba przerwać przepływ , przełączając się między działaniami rozwojowymi a kontrolą jakości.
Gdy w zespole są testerzy, takie rzeczy są naprawdę proste i można z nimi łatwiej sobie poradzić. To, co rzucił na ciebie „starszy” programista, jest w zasadzie wymogiem testowania.
Po każdej zmianie dokonanej w projekcie lub bibliotece upewnij się, że kompilacja się powiodła.
Kroki, które należy wykonać, to typowe działania związane z kontrolą jakości: wyjaśnienie szczegółów wymagań, zaprojektowanie sformalizowanego scenariusza testowego, negocjowanie sposobu postępowania w przypadku niepowodzenia testów.
- Z punktu widzenia SQA jest to dość rutynowe zadanie polegające na zaprojektowaniu, skonfigurowaniu i utrzymaniu dość prostej procedury testowania regresji , która mogłaby być wysoce zautomatyzowana - prawdopodobnie do tego stopnia, że jedynie ręczne działanie polegałoby na tworzeniu i utrzymywaniu biletów w narzędziu do śledzenia problemów i weryfikacji poprawki