Napisałem kilka algorytmów sortowania dla przypisania klasy, a także napisałem kilka testów, aby upewnić się, że algorytmy zostały poprawnie zaimplementowane. Moje testy mają tylko 10 linii i są 3 z nich, ale tylko 1 linia zmienia się między 3, więc jest dużo powtarzającego się kodu. Czy lepiej przekodować ten kod na inną metodę, która jest następnie wywoływana z każdego testu? Czy nie musiałbym wtedy pisać kolejnego testu, aby przetestować refaktoryzację? Niektóre zmienne można nawet przenieść na poziom klasy. Czy klasy i metody testowania powinny podlegać tym samym zasadom, co zwykłe klasy / metody?
Oto przykład:
[TestMethod]
public void MergeSortAssertArrayIsSorted()
{
int[] a = new int[1000];
Random rand = new Random(DateTime.Now.Millisecond);
for(int i = 0; i < a.Length; i++)
{
a[i] = rand.Next(Int16.MaxValue);
}
int[] b = new int[1000];
a.CopyTo(b, 0);
List<int> temp = b.ToList();
temp.Sort();
b = temp.ToArray();
MergeSort merge = new MergeSort();
merge.mergeSort(a, 0, a.Length - 1);
CollectionAssert.AreEqual(a, b);
}
[TestMethod]
public void InsertionSortAssertArrayIsSorted()
{
int[] a = new int[1000];
Random rand = new Random(DateTime.Now.Millisecond);
for (int i = 0; i < a.Length; i++)
{
a[i] = rand.Next(Int16.MaxValue);
}
int[] b = new int[1000];
a.CopyTo(b, 0);
List<int> temp = b.ToList();
temp.Sort();
b = temp.ToArray();
InsertionSort merge = new InsertionSort();
merge.insertionSort(a);
CollectionAssert.AreEqual(a, b);
}
givenThereAreProductsSet(amount)
a nawet tak proste jakactWith(param)
.givenThereAre(2).products()
Raz udało mi się to zrobić płynnie (np. ), Ale szybko przestałem, ponieważ czułem się jak przesada.Jak już powiedział Oded, kod testowy nadal musi zostać utrzymany. Dodam, że powtarzanie w kodzie testowym utrudnia opiekunom zrozumienie struktury testów i dodawanie nowych testów.
W dwóch opublikowanych funkcjach następujące wiersze są absolutnie identyczne, z wyjątkiem jednej różnicy spacji na początku
for
pętli:Byłby to idealny kandydat do przejścia do jakiejś funkcji pomocniczej, której nazwa wskazuje, że inicjuje dane.
źródło
Nie, nie jest ok. Zamiast tego należy użyć TestDataBuilder . Powinieneś także zadbać o czytelność swoich testów: a? 1000? b ? Jeśli jutro będzie trzeba pracować nad implementacją, którą testujesz, testy to świetny sposób na wejście w logikę: napisz swoje testy dla was, innych programistów, a nie dla kompilatora :)
Oto Twoja implementacja testów, „przerobiona”:
źródło
Co więcej niż kod produkcyjny, kod testowy musi być zoptymalizowany pod kątem czytelności i łatwości konserwacji, ponieważ musi być utrzymywany wzdłuż testowanego kodu, a także czytany jako część dokumentacji. Zastanów się, w jaki sposób skopiowany kod może utrudnić utrzymanie kodu testowego i jak może to stać się zachętą do nie pisania testów na wszystko. Nie zapominaj również, że kiedy piszesz funkcję do OSUSZANIA swoich testów, powinna ona również podlegać testom.
źródło
Powielanie kodu do testów jest łatwą pułapką. Pewnie, że jest to wygodne, ale co się stanie, jeśli zaczniesz refaktoryzować kod implementacyjny, a wszystkie testy zaczną wymagać zmiany? Ryzykujesz tak samo, jak w przypadku duplikacji kodu implementacji, ponieważ najprawdopodobniej będziesz musiał zmienić kod testowy również w wielu miejscach. Wszystko to składa się na ogromną stratę czasu i rosnącą liczbę punktów awarii, z którymi trzeba sobie poradzić, co oznacza, że koszty utrzymania oprogramowania stają się niepotrzebnie wysokie, a tym samym zmniejszają ogólną wartość biznesową oprogramowania pracować nad.
Weź również pod uwagę, że to, co jest łatwe do zrobienia w testach, stanie się łatwe do wykonania we wdrożeniu. Kiedy odczuwasz presję czasu i stresu, ludzie polegają na wyuczonych wzorcach zachowań i zazwyczaj starają się robić to, co w danym momencie wydaje się najłatwiejsze. Tak więc, jeśli okaże się, że wycinasz i wklejasz dużo kodu testowego, prawdopodobnie zrobisz to samo w kodzie implementacyjnym, i to jest nawyk, którego chcesz unikać na początku swojej kariery, aby zaoszczędzić ci dużo trudności później, gdy będziesz musiał zachować starszy kod, który napisałeś, i że Twojej firmy niekoniecznie stać na przepisanie.
Jak powiedzieli inni, stosujesz zasadę SUCHA i szukasz okazji do refaktoryzacji wszelkich prawdopodobnych duplikacji metod pomocniczych i klas pomocniczych, i tak, powinieneś nawet robić to w testach, aby zmaksymalizować ponowne użycie kodu i zapisać później będziesz mieć trudności z utrzymaniem. Być może nawet powoli opracowujesz testowy interfejs API, którego możesz używać w kółko, być może nawet w wielu projektach - z pewnością tak właśnie się stało w ciągu ostatnich kilku lat.
źródło