Jak się ustrzec przed tego typu błędami

Ostatnio w programie znalazłem bład typu:

private string a;

public string A
{
    get { return a; }
    set { a = value; }
}

public string B
{
    get { return a; }
    set { a = value; }
}

Musiałem na szybko przekopiować kod i zapomnieć zmienić zmiennej leżącej pod property.
Mam pytanie czy da się w ogóle ustrzec przed takimi błędami czy jedynie można je wykryć podczas działania aplikacji i potem bawić się w detektywa co jest nie tak.

Przecież nie będę pisał dla każdej klasy testów typu:

obiekt.A = "1";
obiekt.B = "2";
obiekt.C = "2";
obiekt.D = "2";

Assert.AreEqual(obiekt.A, "1");

i tak dla każdego property... Pojedyncze testy nie wykazują błędów, dopiero uruchomienie ich w konkretnej sekwencji może ujawnić tego typu błąd. Żeby wykryć ten sam błąd podczas działania programu też należałoby wykonać konkretne czynności w konkretnej kolejności - mogło się zdarzyć że ten błąd istniałby latami bez wykrycia.

Tak więc - czy jest to rodzaj błędu który musi czekać na ręczne wykrycie?

Dlaczego nie uzyjesz po prostu:

public string A { get; set; }

gdfgd napisał(a):

Dlaczego nie uzyjesz po prostu:

public string A { get; set; }

to uproszczony przykład, nie ma wiele wspólnego z kodem
poza tym nie o tym jest temat

kamikaze_222 napisał(a):

Musiałem na szybko przekopiować kod i zapomnieć zmienić zmiennej leżącej pod property.
Mam pytanie czy da się w ogóle ustrzec przed takimi błędami czy jedynie można je wykryć podczas działania aplikacji i potem bawić się w detektywa co jest nie tak.

Tak, przede wszystkim nie kopiować kodu.

Pojedyncze testy nie wykazują błędów, dopiero uruchomienie ich w konkretnej sekwencji może ujawnić tego typu błąd.

W takim razie trzeba napisać testy dla sekwencji działań, które mogą do błędu doprowadzić.

kamikaze_222 napisał(a):

to uproszczony przykład, nie ma wiele wspólnego z kodem

Więc podaj przykład, który ma coś wspólnego z kodem. Bo jak na razie, to uwaga kolegi wyżej jest rozwiązaniem tego "problemu".

Jak się ustrzec przed tego typu błędami

Jest niemożliwe ustrzeżenie się przed wszystkimi możliwymi błędami.
Błędy należy po prostu poprawiać.

Nie używać zmiennych typu string. :P

// Wyjaśnienie: jakby obie zmienne były innego typu, to by kod Ci się nie skompilował. Nie należy używać typów prostych w kodzie biznesowym, należy je opakowywać w typy, które więcej mówią. Np. używać konkretnych typów typu Address / Money, zamiast string i int. Wtedy znacznie trudniej o takie błędy, choć oczywiście gwarancji nadal nie ma, jeśli gdzieś mamy dwa pola typu Address.

Potwierdzam to co napisał @Krolik. Już kilka razy w życiu złapałem się na taką głupią rzecz. Z zasady nie należy używać prymitywów (tzn należy je opakowywać), bo rodzi to same kłopoty. Szczególnie kiedy potem nagle zwracasz z jakiejś funkcji potworki typu
Map<String,Map<Integer, List<Date>>
Wtedy człowiek zaczyna myśleć że chyba sensowniejsze byłoby opakowywanie tego ;)