Prawidłowe testy jednostkowe dla rozbudowanych przypadków

Hej,

Piszemy obecnie aplikację integracyjną z systemem klienta. Generalnie mamy dość specyficzną logikę dotyczącą kalkulacji kosztów wysyłki, ponieważ zależy to od metody dostawy, typu płatności, wartości zakupów, koszt dla kupującego i paru elementów z jego wewnętrznego systemu. W rezultacie mamy klasę, która zwraca nam obiekt przechowujący koszty oraz informacje w postaci flagi czy w ogóle dodawać ten koszt. Niemniej samą implementację napisaliśmy całkiem w porządku i nie ma z nią problemów

Z braku czasu (nie ciągnijmy tego długa historia, słaba organizacja zespołu, ogólnie uciekam stamtąd) zdecydowałem się na napisanie powierzchownych testów, które wyglądają mniej więcej w taki sposób jak widzicie podaje parametrze rezultat i testuje tylko powierzchownie jakieś tam przypadki - te najbardziej problematyczne. Bardziej mnie interesuje fakt jak podchodzicie do takich testów czy zawsze piszecie wszystkie przypadki czy uwzględniając czas, złożoność, ilość testów do napisania stosujecie czasem takie obejścia jak poniżej.

        [Theory]
        [InlineData("Allegro Kurier DPD", 600, 12.99,11.99)]
        [InlineData("Allegro Kurier DPD", 700, 0, 3.99)]
        [InlineData("Allegro Kurier DPD pobranie", 600, 16.99, 15.99)]
        [InlineData("Allegro miniKurier24 InPost pobranie", 600, 13.41, 13.41)]
        public void SellerAndBuyerCost_Should_Be_Given(string deliveryMethod, double totalPrice, double buyerCost, double sellerCost)
        {
            var result = this._deliveryCostCalculator.Calculate(totalPrice, buyerCost, deliveryMethod);
            Assert.Equal(result.BuyerCost, buyerCost);
            Assert.Equal(result.SellerCost, sellerCost);
            Assert.True(result.IsDeliveryCost); 
        }

Jeżeli miałbym samodzielnie zaimplementować taki kalkulator od zera mając podane wymagania i algorytm jego działania, to napisałbym testy do wszystkich przypadków.
Jeśli testów nie ma, a ktoś zgłosi buga, to piszę testy reprodukujące tego buga i naprawiam. Zgłaszam przy tym dług techniczny związany z brakiem testów.

Nawet jeśli implementacja teraz jest dobra i działa, to gdy dojdzie np. nowa metoda dostawy, to podczas jej implementacji ktoś może zepsuć coś w obliczeniach dla poprzednich metod. Posiadanie testów jednostkowych pozwala łatwo zweryfikować, czy nic nie zostało zepsute.