anonimowy napisał(a):
@Riddle: Czyli jeśli klasa/metoda zwraca listę plików i w teście sprawdzamy co zawiera ta lista to znaczy, że uzależniliśmy się od implementacji?
Możliwe że tak, możliwe że nie. Musiałbym się zapoznać z testem żeby Ci powiedzieć.
W ogóle już błąd na starcie, bo zaczynasz "jeśli metoda zwraca listę", czyli mówisz o implementacji w nie o spodziewnym zachowaniu.
Jeśli każdy z systemów ma swoją charakterystykę która jest ci znana i za nic nie chcesz sortować ani ładować zawartości do kontrolowanej przez ciebie struktury danych to chyba nie pozostaje nic innego jak stworzenie oddzielnych strategii dla każdego z systemów.
W ten sposób większość implementacji pozostanie uwspólniona, odseparowane zostaną od siebie wyłącznie asercje które zgodnie z założeniami mają być inne.
Abstrahując od pobocznego problemu którym jest sens robienia tego to taki sposób wydaje mi się najlepszy.
var napisał(a):
Jeśli każdy z systemów ma swoją charakterystykę która jest ci znana i za nic nie chcesz sortować ani ładować zawartości do kontrolowanej przez ciebie struktury danych to chyba nie pozostaje nic innego jak stworzenie oddzielnych strategii dla każdego z systemów.
W ten sposób większość implementacji pozostanie uwspólniona, odseparowane zostaną od siebie wyłącznie asercje które zgodnie z założeniami mają być inne.
A wypowiesz się o tych charakterystykach? Bo właśnie o to zadałem pytanie na forum tutaj.
Właśnie sobie uświadomiłem, że kolega @Riddle zmaga się z problemem tego testu od prawie miesiąca.
To, czego mamy okazję doświadczać w tym wątku wydaje się być wyjątkowo chroniczną odmianą bikesheddingu.
A wystarczy posortować (edit: sortować w testach)...
wartek01 napisał(a):
- Wiem, że miało nie być "olej kolejność plików", ale jeśli musisz zmieniać poprawny z punktu biznesowego kod tylko po to, żeby napisać test to trochę słabo moim zdaniem. Prędzej zastanowiłbym się nad wyklepaniem innego testu.
No właśnie o to chodzi że nie chcę go zmieniać ;| Zmienilbym go, gdybym dodał sortowanie, ale to nie potrzebne.
- Napisz własny formatter do listowania katalogu i plików, napisz test i elo, pora na CSa.
Pisałem już trylion razy, że napisanie swojego formatera przywiązuje implementację do testow, przez co stają się mniej odporne.
Z tego co rozumiem, jedyny sposób ogarnięcia tego, to jest ogarnać każdy system plików, nauczyć się rożnic pomiędzy nimi , przewidzieć jaka będzie kolejnosc, i napisać testy na podstawie tego - to jest dokładnie to o co zapytalem w tym wątku. Zamiast tego dostałem 10 stron odpowiedzi które sugerują albo sortownaie albo parsowanie, czyli coś co napisalem w pierwszym poście, że wiem że mogę to zrobić, ale nie chcę.
Riddle napisał(a):
Mógłbym to ogarnąć, po prostu sortując pliki, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów., dodaje też niepotrzebny overhead performance'owy, którego nie chcę w aplikacji.
Chciałbym napisać test pod wyprintowany output, ale asercje failują na różnych systemach plików przez kolejność właśnie. Mógłbym je prasować, i porównać bez sprawdzenia kolejności, ale to z kolei sprawia że testy są bardziej przywiązane do widoku, bo muszą go prasować. Mógłbym też je testować niżej, zanim się wyprintują.
Jakie mam opcje według was, co do ogarnięcia różnic w kolejności plików w systemie plików? Może skorzystać z wirtualnych systemów plików in-memory na potrzeby testów - ale nadal jest problem ze po uruchomieniu nadal aplikacja ma różnicę.
Proszę się wstrzymać od odpowiedzi "olej kolejność plików" bardzo proszę.
Nie wiem jak inaczej mogę poprosić forumowiczów, żeby nie proponowali rozwiązań które jasno odrzuciłem w pierwszym poście.
Riddle napisał(a):
Nie wiem jak inaczej mogę poprosić forumowiczów, żeby nie proponowali rozwiązań które jasno odrzuciłem w pierwszym poście.
W pierwszym poście napisałeś też, że Nie ma to specjalnego wpływu na działanie aplikacji, poza jednym(logi), więc nie dziw się, że zamiast wachlarza rozwiązań dostałeś jedno, najprostsze i najskuteczniejsze.
Ja serio nie rozumiem co za różnica czy w logu będzie a,b,c czy b,a,c czy a,c,b. Ważne, żeby niezależnie od systemu zgadzała się liczba elementów. Reszta to sztuka dla sztuki.
tajny_agent napisał(a):
Riddle napisał(a):
Nie wiem jak inaczej mogę poprosić forumowiczów, żeby nie proponowali rozwiązań które jasno odrzuciłem w pierwszym poście.
W pierwszym poście napisałeś też, że
Nie ma to specjalnego wpływu na działanie aplikacji, poza jednym(logi), więc nie dziw się, że zamiast wachlarza rozwiązań dostałeś jedno, najprostsze i najskuteczniejsze.Ja serio nie rozumiem co za różnica czy w logu będzie a,b,c czy b,a,c czy a,c,b.
No właśnie nie ma różnicy. Czy jest a,b,c, czy b, a, c, czy a, c, b. Nie ma, i dlatego chcę napisać dobry test pod to. Jest natomiast róznica czy byloby a,b,c vs. a, b, b, albo a, d, d.
tajny_agent napisał(a):
Ważne, żeby niezależnie od systemu zgadzała się liczba elementów. Reszta to sztuka dla sztuki.
Muszą się zgadzać ścieżki, tzn ma nie być duplikatów, ma nie być nadmiarowych, i nie ma żadnych brakować, ale kolejność jest nieistotna. Nie chce żeby mi testy failowały, jak program wyprintuje w innej kolejności. (I jesli masz teraz zaproponowac - to sortuj albo parsuj output, to proszę powstrzymaj się).
Jedyna osoba w tym wątku która skumała, w miarę o co chodzi był @var w tej wypowiedzi:
var napisał(a):
Jeśli każdy z systemów ma swoją charakterystykę która jest ci znana i za nic nie chcesz sortować ani ładować zawartości do kontrolowanej przez ciebie struktury danych to chyba nie pozostaje nic innego jak stworzenie oddzielnych strategii dla każdego z systemów.
W ten sposób większość implementacji pozostanie uwspólniona, odseparowane zostaną od siebie wyłącznie asercje które zgodnie z założeniami mają być inne.
Tylko mój problem jest taki że własnie nie znam dokładnej charakterystyki systemów plików, dlatego założyłem ten wątek, z nadzieją że ktoś zna i się podzieli wiedzą.
Niestety nikt się nie podzielił, a dostałem tylko 100 postów o tym że sortuj albo parsuj.
Pisałem już trylion razy, że napisanie swojego formatera przywiązuje implementację do testow, przez co stają się mniej odporne.
to posortuj w testach.
log:
File List: a c b
File List: b c a
i niech test ma jakiś OutputNormalizer który normalizuje te outputy tak, aby dało się je porównywać (np. nazwy plików są sortowane).
Przecież jeżeli Ty generujesz ten output, to parsnięcie tego będzie banalne.
Tu nie ma żadnego couplingu pomiędzy testami i implementacją.
Z tego co rozumiem, jedyny sposób ogarnięcia tego, to jest ogarnać każdy system plików, nauczyć się rożnic pomiędzy nimi , przewidzieć jaka będzie kolejnosc, i napisać testy na podstawie tego
no tak, po co zrobić ""nieładnie"" gdy można zrobić topornie:
dużo więcej kodu
dużo więcej wiedzy do przekazania przy wdrażaniu kogoś
ciągłe potrzeby dopisywania kodu (nowe fsy)
Riddle napisał(a):
No właśnie nie ma różnicy. Czy jest
a,b,c, czyb, a, c, czya, c, b. Nie ma, i dlatego chcę napisać dobry test pod to. Jest natomiast róznica czy bylobya,b,cvs.a, b, b, alboa, d, d.
Pewnie tego pożałuję... Skoro nie ma różnicy (kolejność jest nieistotna), to dlaczego tę kolejność bierzesz pod uwagę? Dlaczego ją zwracasz w jakiejś liście, zamiast użyć zbioru? Zmień typ zwracany z listy na zbór, porównaj czy jest tożsamy ze zbiorem oczekiwanym job done.
piotrpo napisał(a):
Riddle napisał(a):
No właśnie nie ma różnicy. Czy jest
a,b,c, czyb, a, c, czya, c, b. Nie ma, i dlatego chcę napisać dobry test pod to. Jest natomiast róznica czy bylobya,b,cvs.a, b, b, alboa, d, d.Pewnie tego pożałuję... Skoro nie ma różnicy (kolejność jest nieistotna), to dlaczego tę kolejność bierzesz pod uwagę? Dlaczego ją zwracasz w jakiejś liście, zamiast użyć zbioru? Zmień typ zwracany z listy na zbór, porównaj czy jest tożsamy ze zbiorem oczekiwanym job done.
Znowu próbujesz mnie przekonać do jednego z dwóch rozwiązań które odrzuciłem, ale niech Ci będzie.
Dlatego, że nie dostaje ich jako kolekcje, dostaje wyprintowany output, i na nim odpalam test. Nie mam zamiaru go prasować, ani nie mam zamiaru zmienić aplikacji żeby sortował output. To jest coś, o czym pisalem już wielokrotnie.
Jestem zainteresowany rozwiązaniem które @var zaproponował w poprzedniej wiadomości Jak poprawnie obsłużyć różną kolejność plików w systemach plików.
@Riddle: W końcu przedstawiłeś problem...
Co z takim podejściem:
Output testowanej jednostki:
output = "abc"
output.replace('a', '').replace('b', '').replace('c', '');
assertEquals(0, output.length)
No to wracamy do propozycji „napisz do Microsoftu, niech Ci pokaże specyfikację NTFS-a”. Jak pracujesz dla naprawdę dużej firmy, to masz szansę, że się zgodzą.
Hmm, a może tak sparować, posortowac.. co o tym myślisz?
Pewnie będę tego żałował...
@Riddle: te tajemnicze "charakterystyki", to można poznać np. w ramach wykładu z "Wprowadzenie do systemów operacyjnych". Dział dotyczący systemów plików, np. https://docplayer.pl/14472050-System-plikow-warstwa-logiczna-warstwa-fizyczna-przyklady-implementacji-systemy-operacyjne-wyklad-6-1.html
Możesz się z tego dowiedzieć, że pod spodem używane są różne struktury danych, np. listy wielopoziomowe, drzewa, grafy, tablice haszujące i Twój problem "różnej kolejności" sprowadza się do "jak obsłużyć różną kolejność elementów w tablicy haszującej i w grafie" (np. dla systemu, który korzysta z grafu oraz dla drugiego systemu, który korzysta z tablicy haszującej).
Ze wstępu do teorii mnogości:
a) Żeby określić kolejność elementów w zbiorze wprowadza się relację, która te elementy porządkuje (określa porządek w zbiorze)
b) Zakładając, że masz te dwa porządki zdefiniowane, na zbiorzeA (NTFS) oraz na zbiorzeB(ext4), można wprowadzić izomorfizm między relacjami
c) konstruujesz taką funkcję zadającą izomorfizm i masz ogarnięte różnice między zbiorem A i zbiorem B
Jak skonstruować taką funkcję? Proste, posortować ;)
Możesz też zrobić krok wstecz i zastanowić się czy testy są na właściwej warstwie. Może powinieneś operować nie na tym co generowane jest na standardowym wyjściu, tylko z warstwy "wyżej" pobrać rezultat (lista logów?) i na tym pracować?
Wiem, wiem, nie tego oczekiwałeś. Mea culpa.