Przykładowy test fragmentu kodu

Witam

Głównym pytaniem jest, w jaki sposób przygotowujecie się do napisania fragmentu kodu, żeby potem nie przeprawiać go po kilkanaście razy + dodatkowo nie przeprawiać klas z nim powiązanych? Bo idzie w nerwice wpaść. ;O

2 sprawa jest taka, w jaki sposób (związane z powyższym) sprawdzacie czy kod działa zanim pościcie go w obieg?

Mam taki przykład

public LiczIle(int[] tablica){
		for (int i: tablica) {
			index = 0;
			for (int j: tablica) {
				
				
				if (tablica[j] == tablica[i]) {
				
				index++;
			}
			else { 
				break;
			}
			
			}
			System.out.print(tablica[i] +" = " + index + " ");
			
		}

Ten fragment to po prostu dramat, jak to ktoś kiedyś powiedział "szkoda strzępić ryja", ile nerwów mnie kosztuje to już nie wspomnę.

O co mi chodzi:

Zanim napisałem te kilka linijek sprawiających, że krew zaczyna szybciej płynąć zapisałem sobie na kartce co frament ma robić i ja ma to przebiec.

Głównym założeniem było, żeby:

• wejść w tablicę,
• wyzerować index,
• dla indexu[i] sprawdzić całą tablicę w poszukiwaniu ile razy element się powtarza,
• wypisać ilość tych razy (zapisaną w zmiennej index, którą inkrementuję w pętli),
• wyzerować index i zacząć z kolejnym elementem.

Dodatkowym założeniem było, żeby nie powtarzało mi 2 razy tych samych elementów w tablicy, czyli dla 2 1 2 mieć wynik : 2 = 2, 1 = 0 zamiast 2 = 2, 1 = 0, 2= 2.

Wypisałem to na kartce, za symulowałem pętle, zadowolony z życia na tej podstawie wypisałem kod i przy elementach 2 1 2 otrzymuję wynik 2 = 1 1 = 0 2 = 1 grr.

W tym poście w ogóle nie chodzi mi o rozwiązanie problemu wyniku, ponieważ to jest najmniejszy problem. Pytania moje to:

• Jak zaplanować pisanie, żeby nie zdziwić się tak bardzo? Bo znając siebie to ja zanim ogarnę sprawę to jeszcze z 5 razy zmienię całą metodę. A chodzi o to, żebym miał zarys tego jak to powinno wyglądać,
• Jak sprawdzić działanie samego tego jednego fragmentu kodu, zanim podpiął bym go pod maina?,
• W jaki sposób to sprawdzić, żeby dojść do rozwiązania

Ostatnia rzecz debugger, w ogóle go nie ogarniam, czasem uda mi się sprawdzić kod metodą "steb by step", którą udostępnia, ale nie zawsze jest ona "aktywna" - naprowadzilibyście mnie na cokolwiek, co pomogło by mi zrozumieć działanie debuggera?

Próbowałem nauczyć się czegoś na własną rękę, jakieś ustalanie breakpointów i właśnie "step by step", ale koniec końców eclipce olewa moje break pointy i kompiluje program z miejsca tak jak bym w ogóle nie używał debuggera ;O

1. Nie uzywaj Eclipse tylko IntelliJ. Serio. Szczególnie jeśli chodzi o możliwosci debuggera.
2. Ten kod to dramat już od samego początku bo lecisz tam na gołej tablicy int[] a poza bardzo szczególnymi względami wydajnosciowymi to jest bardzo zły pomysł. Daj tam po ludzku jakies List<Integer>
3. Kolejny błąd to skupienie sie na tym JAK coś zrobić (a twój pomysł jest głupi i zły tak btw) a nie CO zrobić. Rozumiem że chciałeś zrobić "zliczanie" elementów.
4. Napisz sobie unit testy zanim zaczniesz pisać kod. Zalecałbym też zwracać z funkcji wynik a nie tylko coś printować. Więc zwracaj Map<Integer, Integer> bo efektywnie to chcesz uzyskać. Możesz więc napisać kilka przypadków testowych dla róznych tablic, tak żeby sprawdzać czy funkcja nadal działa.
5. Ta funkcja powinna wyglądać tak:

    public <T> Map<T, Long> count(List<T> inputData) {
        return inputData.stream()
                .collect(Collectors.groupingBy(
                        element -> element,
                        Collectors.counting()
                ));
    }

Bez żadnych ifów, breaków i innych cudów i jeszcze jest <T> więc zadziała dla listy dowolnych obiektów, nie tylko intów.
Jak bardzo nie chcesz użyc Stream API i Javy 8 to można też tak:

    public <T> Map<T, Long> countWithoutStream(List<T> inputData) {
        Map<T, Long> counts = new HashMap<>();
        for(T element : inputData){
            long currentCounterForElement = counts.getOrDefault(element, 0L);
            counts.put(element, currentCounterForElement+1);
        }
        return counts;
    }

Test mógłby wyglądać tak:

    @Test
    public void testCounting(){
        List<Integer> first = Arrays.asList(1,2,3,1,2);
        Map<Integer, Long> firstExpected = new HashMap<>(
                Stream.of(
                        new AbstractMap.SimpleEntry<>(1,2L),
                        new AbstractMap.SimpleEntry<>(2,2L),
                        new AbstractMap.SimpleEntry<>(3,1L)
                ).collect(Collectors.toMap(
                        AbstractMap.SimpleEntry::getKey,
                        AbstractMap.SimpleEntry::getValue
                ))
        );
        Counter counter = new Counter();
        assertEquals(firstExpected, counter.count(first));
        assertEquals(firstExpected, counter.countWithoutStream(first));
    }

W sumie jak już mamy takie dwie implementacje to mozemy też zrobić sobie taki zabawny test, który będzie sprawdzał czy obie implementacje daję takie same wyniki!
Możemy wygenerować sobie pewną liczbę identycznych testów "w locie" generując dla każdego losowe dane, a w teście sprawdzać tylko czy obie metody dają ten sam wynik:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

import java.util.List;
import java.util.Random;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

import static org.junit.Assert.assertEquals;

@RunWith(Parameterized.class)
public class ParametrizedTest {
    private static final int testsNumber = 10;
    private static final int randomNumbersToUse = 10;
    private static final int upperBound = 10;

    private final List<Integer> inputData;

    public ParametrizedTest(List<Integer> inputData) {
        this.inputData = inputData;
    }

    @Test()
    public void testCounters() {
        Counter counter = new Counter();
        assertEquals(counter.count(inputData), counter.countWithoutStream(inputData));
    }

    @Parameterized.Parameters
    public static List<List<Integer>> generateTestData() {
        return IntStream.range(0, testsNumber)
                .mapToObj(_index -> generateInputList(randomNumbersToUse, upperBound))
                .collect(Collectors.toList());
    }

    private static List<Integer> generateInputList(int randomNumbersToUse, int upperBound) {
        Random random = new Random();
        return IntStream.range(0, randomNumbersToUse)
                .mapToObj(_index -> random.nextInt(upperBound))
                .collect(Collectors.toList());
    }
}

1. Ściągam już IntelijJ, więc odhaczone.
2. Nie wiem jak rozumieć "gołej". Ta funkcja pobiera dane z innego miejsca.
3. Czemu skupienie się na sposobie wykonania zadania jest tym złym w stosunku do skupienia się na tym jakie zadania ma być wykonane?
4. Zapoznam się z unit testami i z pewnością zastosuję się do tej rady.
5. Odniosę się podsumowując.

Generalnie moja wiedza jest bardzo, bardzo podstawowa, nie znam akurat list, lambd i innych cudów więc ich nie wykorzystywałem.

W tym momencie działając na tablicy jedyne co mi przychodziło do głowy do ify. Jestem na samej linii startu jeśli idzie o javę, więc gdy tylko zrobię coś podsumowującego te podstawy, które znam, będę poszerzać wiedzę. W tym momencie linijki, kodu, które mi wskazałeś są dla mnie w ogóle nie zrozumiałe. Gdy tylko zrozumiem to na czym teraz operuję, zacznę przechodzić do nowych rzeczy,

Dopiero później spostrzegłem co napisałeś w edycji. Generalnie mam rozumieć, że tego co chcę zrobić nie da się zrobić ifami?

2. Jeśli w ogóle w kodzie żonglujesz jakimiś tablicami w stylu int[] to dobrze nie wróży. A jeśli dostajesz to z zewnętrznego API to konwertuj na listę i będzie sie z tym 100 razy wygodniej pracowało. O ile nie piszesz teraz jakiegoś HFT, Big Data ani kodu na jakiś słaby system embedded to nie ma sensu utrudniać sobie życia.
3. Bo zwykle kończy się zafixowaniem na błędnym i bardzo skomplikowanym rozwiązaniu. I potem zamiast myśleć o tym co w ogóle chciałeś osiągnąć skupiasz się na tym jak poprawić kod który napisałeś. Tu na forum widać to bardzo bardzo często -> ludzie przychodzą z pytaniem "jak zrobić X" gdzie X to jakaś mega karkołomna konstrukcja, podczas gdy potrzebują czegoś dużo prostszego. Ale wymyślili że tą prostą rzecz można by zrobić przez X i kombinują teraz nad X zamiast nad tym prostym wyjściowym problemem.

Oczywiście ze "da się" ifami, tylko będzie dużo trudniej i mniej czytelnie. Bo na przykład żeby wykluczyć "powtórzenia" musialbyś gdzieś pamiętać juz przetworzone liczby, wiec musiałbyś napisać sobie jakiś Set<T>, albo przynajmniej mieć drugą tablicę w której byś sprawdzał czy dana liczba już padła.