Jak poprawnie obsłużyć różną kolejność plików w systemach plików.

pms_enable_synaptics napisał(a):

Sortować w testach :D

Powtarzam to już dziesiąty raz - sortowanie outputu w testach wiązałoby się z przywiązanie testów do implementacji, także proszę przestać proponować to rozwiązanie.

To rozdziel metodę publiczną zwracającą string od metody zbierającej pliki

i przetestuj tą prywatną operującą na jakichś abstrakcjach typu List<File>

Riddle napisał(a):

pms_enable_synaptics napisał(a):

Sortować w testach :D

Powtarzam to już dziesiąty raz - sortowanie outputu w testach wiązałoby się z przywiązanie testów do implementacji

Nope.

A nie sortowanie outputu w testach wiązałoby się z napisaniem logiki reimplementującej coś, co jest palcem po wodzie pisane, i może się zmienić w dowolnym momencie, bez żadnego powodu, w sposób kompletnie nieprzewidywalny.

Pick your poison.

Althorion napisał(a):

A nie sortowanie outputu w testach wiązałoby się z napisaniem logiki reimplementującej coś, co jest palcem po wodzie pisane, i może się zmienić w dowolnym momencie, bez żadnego powodu, w sposób kompletnie nieprzewidywalny.

Nie wiemy tego. Dlatego zadałem to pytanie, żeby się wypowiedział ktoś kto się na tym zna.

Riddle napisał(a):

Powtarzam to już dziesiąty raz - sortowanie outputu w testach wiązałoby się z przywiązanie testów do implementacji, także proszę przestać proponować to rozwiązanie.

Czyli wolisz przywiązać się do implementacji czegoś, czego nawet nie kontrolujesz :D

spaghetticoder napisał(a):

Riddle napisał(a):

Powtarzam to już dziesiąty raz - sortowanie outputu w testach wiązałoby się z przywiązanie testów do implementacji, także proszę przestać proponować to rozwiązanie.

Czyli wolisz przywiązać się do implementacji czegoś, czego nawet nie kontrolujesz :D

Nie ma czegoś takiego jak "przywiązanie do implementacji".

Od implementacji, z definicji, nic nie powinno zależeć.

PS: W odpowiedzi niżej jasno widać, że autor nie zrozumiał o co chodziło, więc może objaśnię - nie uzależnię się od implementacji, bo od implementacji z definicji nie należy się uzależniać. Po prostu zastosuję pewną implementację, ale w taki sposób, że będzie się ją potem dało zmienić na inną, i nic innego w aplikacji nie powinno wtedy ulec zmianie (odwrotnie niż w przypadku testów, które musiałyby się zmienić, gdybym zmienił output albo zdecydował o sortowaniu lub nie).

To dlaczego chcesz przywiązywać się do implementacji systemów plików, każdego z osobna, w swoich testach?

@Riddle: Czyli jeżeli przeniesiesz build i wykonanie testów z maszyny pod biurkiem, na, dajmy na to, pipeliny w jakimś Azure DevOps, to wyniki testów tego twojego docelowego rozwiązania nie ulegną zmianie?

piotrpo napisał(a):

@Riddle: Czyli jeżeli przeniesiesz build i wykonanie testów z maszyny pod biurkiem, na, dajmy na to, pipeliny w jakimś Azure DevOps, to wyniki testów tego twojego docelowego rozwiązania nie ulegną zmianie?

Nie. Jeśli napiszę je poprawnie, to nie.

Głupotą byłoby napisać testy które failują, kiedy się je przeniesie na inny system plików.

Czy ten temat nie przybliża się powoli do działu Perełki? Tak tylko pytam.

@Riddle:

Nie ma czegoś takiego jak "przywiązanie do implementacji".
Od implementacji, z definicji, nic nie powinno zależeć.

Tak brzmi teoria, a rzeczywistość jest zgoła inna

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

I teraz zastanawiasz się trzeci tydzień jak napisać to """ładnie""", a junior by sortnął stringi i zamknął temat 3 tygodnie temu

i nieświadome rozwiązał problem który zajmuje miesiąc doświadczonemu inżynierowi :P

@Riddle: Czyli jak rozumiem, zamierzasz zmierzasz tam umieścić różne asercje dla wszystkich istniejących systemów plików oraz sprawdzać na jakiej wersji systemu i jakim systemie plików zostały uruchomione?
Czy to co piszesz ma działać tylko i wyłącznie na określonych systemach plików? Np. robisz oprogramowanie do backupu, defragmentacji, naprawiania tablic plików itp? Czy jednak możesz sobie pozwolić na traktowanie pamięci trwałej jako pewnej abstrakcji i jak tam wstawisz np. jakiś blobstorage, dopiszesz adapter, to też będzie OK? Czy działanie twojej aplikacji jest zależne od tej kolejności zwracanej przez jakiś tam stos komponentów, nad którymi nie masz kontroli?

piotrpo napisał(a):

@Riddle: Czyli jak rozumiem, zamierzasz zmierzasz tam umieścić różne asercje dla wszystkich istniejących systemów plików oraz sprawdzać na jakiej wersji systemu i jakim systemie plików zostały uruchomione?

Nie, to byłoby przywiązanie testów do systemu plików, i byłoby bardzo złym pomysłem.

Czy to co piszesz ma działać tylko i wyłącznie na określonych systemach plików? Np. robisz oprogramowanie do backupu, defragmentacji, naprawiania tablic plików itp? Czy jednak możesz sobie pozwolić na traktowanie pamięci trwałej jako pewnej abstrakcji i jak tam wstawisz np. jakiś blobstorage, dopiszesz adapter, to też będzie OK? Czy działanie twojej aplikacji jest zależne od tej kolejności zwracanej przez jakiś tam stos komponentów, nad którymi nie masz kontroli?

Nie chce mi się tłumaczyć jak pisać dobre testy, na pewno znajdziesz dużo źródeł na ten temat na forum i w internecie.

Riddle napisał(a):

piotrpo napisał(a):

@Riddle: Czyli jak rozumiem, zamierzasz zmierzasz tam umieścić różne asercje dla wszystkich istniejących systemów plików oraz sprawdzać na jakiej wersji systemu i jakim systemie plików zostały uruchomione?

Nie, to byłoby przywiązanie testów do systemu plików, i byłoby bardzo złym pomysłem.

To oświeć wszystkich jakiego typu rozwiązania szukasz?
Skoro wynik jest zależny od systemu plików i nawet od tego co wcześniej się działo na dysku twardym i chcesz żeby działało to na każdym możliwym systemie plików i każdej możliwej kombinacji (oprócz systemu plików @overcq), ale jednocześnie nie chcesz sprawdzać jaki system plików jest używany i nie chcesz doprowadzić wyjścia programu do formatu kompatybilnego z testami (przez posortowanie) to jak wyobrażasz sobie możliwe rozwiązanie?

// edit:
Dobra, zadając to pytanie wpadłem jednocześnie na odpowiedź (głupią bo głupią ale jednak...):

wrzuć pliki o oczekiwanych nazwach do innego folderu obok w tej samej kolejności utworzenia i je wylistuj - jest duże prawdopodobieństwo że wylistują się w dokładnie tej samej kolejności więc możesz je wtedy porównać bez sortowania

Riddle napisał(a):

Althorion napisał(a):

A nie sortowanie outputu w testach wiązałoby się z napisaniem logiki reimplementującej coś, co jest palcem po wodzie pisane, i może się zmienić w dowolnym momencie, bez żadnego powodu, w sposób kompletnie nieprzewidywalny.

Nie wiemy tego. Dlatego zadałem to pytanie, żeby się wypowiedział ktoś kto się na tym zna.

Wiemy. Możesz sobie poczytać specyfikację dla linuksowych systemów plików — nie znajdziesz tam nic o gwarantowanej kolejności odczytu. Implementacja w Linuksie tego nie gwarantuje. Może się zmienić. Będzie się zmieniać. Zmieniała się w przeszłości — zobacz sobie problemy z portowaniem Cywilizacji 5, bo ona miała dokładnie ten sam problem (założoną kolejność odczytu plików, która się rozleciała).

A specyfikacji NTFS-a w ogóle nie dostaniesz, jeśli nie jesteś wielkim enterprise’em, z którym Microsoft się czymś takim podzieli. I znowu — nikt Ci nie daje gwarancji kolejności, zmieniało się to w przeszłości, jest bardzo prawdopodobne, że zmieni się i w przyszłości.

Jak chcesz mieć system, który daje taką gwarancję, to musisz go sobie zrobić. Musisz napisać swoje własne moduły do obsługi systemu plików. A jak to zrobisz, to zobaczysz, że dyski Cię mogą okłamywać co do faktycznej struktury danych na nich (w szczególności SSD lubią to robić). Więc pewnie byś musiał jeszcze swoje sterowniki do nich napisać. I pewnie jeszcze firmware. I tak do wszystkiego, co chcesz wspierać.

Bo, kurde, nie ma innej opcji. I to nie jest jakaś „niewiadoma” — poczytaj sobie znane specyfikacje. Jak znajdziesz w nich gwarancję, to ta gwarancja jest. Ale prawie nigdzie nie znajdziesz. Więc jak „gotowce” Ci tego nie gwarantują, to musisz to sobie zagrawantować sam.

Riddle napisał(a):

Nie chce mi się tłumaczyć jak pisać dobre testy, na pewno znajdziesz dużo źródeł na ten temat na forum i w internecie.

Jak na razie. z Twoich wypowiedzi w tym wątku wygląda, że to nie jest kwestia "nie chce mi się", tylko "nie mam pojęcia czym są dobre testy".

piotrpo napisał(a):

Riddle napisał(a):

Nie chce mi się tłumaczyć jak pisać dobre testy, na pewno znajdziesz dużo źródeł na ten temat na forum i w internecie.

Jak na razie. z Twoich wypowiedzi w tym wątku wygląda, że to nie jest kwestia "nie chce mi się", tylko "nie mam pojęcia czym są dobre testy".

Robisz off-topic, bo odchodzisz od tematu systemu, plików, ale niech Ci będzie:

Dla mnie, dobre testy to są takie które:

• Wykonują się błyskawicznie
• Jest ich dużo
• Są małe
• Failują za każdym razem kiedy w aplikacji jest bug
• Nie failują w każdym przypadku kiedy w aplikacji nie ma buga (np kiedy refaktorujemy, zmieniamy implementację, robimy update biblioteki który nic nie psuje, etc.)
• Nie wymagają zmiany, wtedy kiedy funkcjonalności aplikacji nie wymagają zmiany.

Żeby osiągnąć wszystkie te elementy, sam widzisz - nie mogę przywiązać testów do implementacji, co znaczy że nie mogę ani parsować outputu w testach, ani pisać osobnych asercji pod różne systemy plików. Rozumiem, że jeśli nie umiesz pisać dobrych testów, oraz masz problem ze zrozumieniem natury tego tematu, łatwo Ci rzucać takie oskarżenia, dziękuję za podzieleniem się opinią.

Mam konkretny cel w głowie, wierz lub nie ale wpadłem wcześniej na pomysł który zasguerowałeś - ale jestem świadom tego że nie wiem wszystkiego, myślę że ktoś się może znać na systemach plików lepiej niż ja; a jednocześnie wiem jakie kryteria chce żeby moja aplikacja spełaniała, jakie moja implementacja ma spełniać, i jakie moje testy mają spełniać. Nic co powiesz, nie przekona mnie żebym dodał feature któryego nie potrzebuję, albo żebym upośledził moje testy w taki sposób jaki proponujesz.

Także, powtarzam - jesli masz coś wartościowego do dodania w kontekście ogarniania róznic pomiędzy systemem plików - proszę, wypowiedz się - jeśli nie, to bardzo proszę nie zaśmiecaj tematu.

Althorion napisał(a):

Riddle napisał(a):

Althorion napisał(a):

A nie sortowanie outputu w testach wiązałoby się z napisaniem logiki reimplementującej coś, co jest palcem po wodzie pisane, i może się zmienić w dowolnym momencie, bez żadnego powodu, w sposób kompletnie nieprzewidywalny.

Nie wiemy tego. Dlatego zadałem to pytanie, żeby się wypowiedział ktoś kto się na tym zna.

Wiemy. Możesz sobie poczytać specyfikację dla linuksowych systemów plików — nie znajdziesz tam nic o gwarantowanej kolejności odczytu. Implementacja w Linuksie tego nie gwarantuje. Może się zmienić. Będzie się zmieniać. Zmieniała się w przeszłości — zobacz sobie problemy z portowaniem Cywilizacji 5, bo ona miała dokładnie ten sam problem (założoną kolejność odczytu plików, która się rozleciała).
A specyfikacji NTFS-a w ogóle nie dostaniesz, jeśli nie jesteś wielkim enterprise’em, z którym Microsoft się czymś takim podzieli. I znowu — nikt Ci nie daje gwarancji kolejności, zmieniało się to w przeszłości, jest bardzo prawdopodobne, że zmieni się i w przyszłości.

Nie przeszkadza mi to, jeśli tylko gdzieś jest dokumentacja z tymi zmianami, albo jakiś ChangeLog.

Nic nowego nie odkryłeś, jest wiele systemów, które zmieniają się w czasie, i jakoś ludzie je utrzymują - np są aplikacje które potrafią wspierać wiele różnych wersji MySQL'a, albo wiele różnych wersji środowisk na których są uruchamiane.

OK. To Linux ma otwarty kernel, ma też publiczną mailistę ze wszystkimi PR-ami. Możesz śledzić i pilnować.

I dalej uważam, że jak chcesz bazować swoje zachowanie na nie udokumentowanej i nie zadeklarowanej cesze, to lecisz po bandzie, i to nie ma nic wspólnego ze wspieraniem kilku wersji dobrze znanej i ustandaryzowanej aplikacji. Bardziej jak „lubię sobie polegać na UB w kodzie”, albo „wrzuciłem do systemu budowania zależność bez pinowania wersji”.

Althorion napisał(a):

I dalej uważam, że jak chcesz bazować swoje zachowanie na nie udokumentowanej i nie zadeklarowanej cesze, to lecisz po bandzie, i to nie ma nic wspólnego ze wspieraniem kilku wersji dobrze znanej i ustandaryzowanej aplikacji. Bardziej jak „lubię sobie polegać na UB w kodzie”, albo „wrzuciłem do systemu budowania zależność bez pinowania wersji”.

Kurcze, gdybym tylko znalazł gdzieś w internecie jakiś wątek w stylu Jak poprawnie obsłużyć różną kolejność plików w systemach plików. i była tam chociaż jedna instrukcja jak to zrobić dobrze....

pomarzyć można.

@Riddle:

Nic nowego nie odkryłeś, jest wiele systemów, które zmieniają się w czasie, i jakoś ludzie je utrzymują - np są aplikacje które potrafią wspierać wiele różnych wersji MySQL'a, albo wiele różnych wersji środowisk na których są uruchamiane.

i jak to robią?

no wieloma ifkami pewnie :P

@1a2b3c4d5e Dependency inversion?

Odpowiedź na to pytanie jest dokładnie taka sama — i z dokładnie takich samych powodów — jak na te wymieniane przeze mnie. „Nie rób tego, zrób mądrze” — „nie polegaj na UB, pisz zgodnie ze specyfikacją”, „nie polegaj na tym, że biblioteka się nigdy nie zmieni, pinuj wersję”. I tutaj wreszcie, „nie próbuj przewidzieć kolejności, standaryzuj ją (sortując)”.

No nie da się uczciwie udzielić innej odpowiedzi. Nieuczciwie, rzecz jasna, można — „jak ci się nie podoba, że to UB, to forkuj język i kompilator i toole, i zrób, żeby był defined”, czyli „naklep swoją implementację, która ci da gwarancje, których szukasz”. Ale słusznie tę opcję odrzucasz. Tylko nie pojmuję — i nie jestem tutaj jedyny — dlaczego uważasz, że jest jakaś ukryta jeszcze inna…

Althorion napisał(a):

Odpowiedź na to pytanie jest dokładnie taka sama — i z dokładnie takich samych powodów — jak na te wymieniane przeze mnie. „Nie rób tego, zrób mądrze” — „nie polegaj na UB, pisz zgodnie ze specyfikacją”, „nie polegaj na tym, że biblioteka się nigdy nie zmieni, pinuj wersję”. I tutaj wreszcie, „nie próbuj przewidzieć kolejności, standaryzuj ją (sortując)”.

No nie da się uczciwie udzielić innej odpowiedzi. Nieuczciwie, rzecz jasna, można — „jak ci się nie podoba, że to UB, to forkuj język i kompilator i toole, i zrób, żeby był defined”, czyli „naklep swoją implementację, która ci da gwarancje, których szukasz”. Ale słusznie tę opcję odrzucasz. Tylko nie pojmuję — i nie jestem tutaj jedyny — dlaczego uważasz, że jest jakaś ukryta jeszcze inna…

Dziękuję za Twoją opinię, przyjąłem ją.

Zdecydowałem nie skorzystać z Twojej rady, teraz bądź tak miły, i jeśli nie masz nic więcej do dodania to nie zaśmiecaj wątku bardzo proszę.

Wygląda na to, że:

• nic nie zrozumiałeś z większości odpowiedzi ludzi, którzy się na tym znają, np z tego co pisał @Althorion
• brniesz w zaparte i w gruncie rzeczy masz dość ograniczone myślenie. Nie chciałbym pracować z kimś takim jak ty. Wyjaśniono ci już wprost, że kolejność plików jest losowa i nie da się jej przewidzieć. Ty dalej brniesz i pytasz jak obsłużyć kolejność plików. Weź sobie generator liczb losowych i załóż temat z pytaniem jak obsłużyć kolejność losowanych liczb. To będzie mniej więcej to samo.

Moim zdaniem ten wątek powinien być już w dziale Perełki.

gajusz800 napisał(a):

Wygląda na to, że:

• nic nie zrozumiałeś z większości odpowiedzi ludzi, którzy się na tym znają, np z tego co pisał @Althorion
• brniesz w zaparte i w gruncie rzeczy masz dość ograniczone myślenie. Nie chciałbym pracować z kimś takim jak ty. Wyjaśniono ci już wprost, że kolejność plików jest losowa i nie da się jej przewidzieć. Ty dalej brniesz i pytasz jak obsłużyć kolejność plików. Weź sobie generator liczb losowych i załóż temat z pytaniem jak obsłużyć kolejność losowanych liczb. To będzie mniej więcej to samo.

Moim zdaniem ten wątek powinien być już w dziale Perełki.

Z mojego punktu widzenia, to wy macie ograniczone myślenie, bo wychodzicie z założenia że nie da się obsłużyć różnic w systemach plików, że równie dobrze ta kolejność mogłaby być losowa.

Albo pokaż mi jakieś źródło które to prezentuje, albo proszę nie zaśmiecaj wątku.

Bardzo proszę, o to żeby przyszłe wpisy w tym wątku były merytoryczne. Tzn. dotyczyły tylko ogarniania kolejności plików w różnych systemach plików, o nic więcej nie pytam. Odpowiedzi w stylu "nie da się", "odpuść sobie" bardzo proszę zachować dla siebie.

Nie no, da się, ale z twoimi wymaganiami ciężko.

Napisz sobie hardware abstraction layer czy jakiś virtualFS który będzie ci normalizował dane w twoim kodzie, a nie testu.

Riddle napisał(a):

Dla mnie, dobre testy to są takie które:

• Wykonują się błyskawicznie
• Jest ich dużo
• Są małe
• Failują za każdym razem kiedy w aplikacji jest bug
• Nie failują w każdym przypadku kiedy w aplikacji nie ma buga (np kiedy refaktorujemy, zmieniamy implementację, robimy update biblioteki który nic nie psuje, etc.)
• Nie wymagają zmiany, wtedy kiedy funkcjonalności aplikacji nie wymagają zmiany.

I który z tych punktów zostanie naruszony, jak pozbędziesz się z układanki elementu nad którym nie masz panowania, a który nie jest częścią funkcjonalności twojej aplikacji?

Na poziomie jakiejś tam abstrakcji przychodzę mi do głowy następujące możliwe scenariusze:

1. Użytkownik aplikacji zaobserwuje błąd jeżeli system zwróci inną kolejność podczas listowania plików.
   1.1 Aplikacja zależy i musi zależeć od kolejności plików. Wtedy albo obsługujesz w teście ileś tam wariantów, które aplikacja ma wspierać, albo badasz w jakiej kolejności system zwraca te pliki i na tej podstawie budujesz expected.
   1.2 Aplikacja nie musi polegać na zwróconej kolejności plików, bo użytkownika to wali. Wtedy masz błąd w aplikacji, bo masz sytuację "u mnie działa". Trzeba uniezależnić działanie aplikacji od kolejności w jakiej zwracane są pliki.
2. Użytkownik nie zaobserwuje błędu, jeżeli system plików się zmieni. W takim przypadku możesz:
   2.1 Ustandaryzować wyjście z aplikacji (czyli dodać sortowanie w aplikacji, albo zwyczajnie zmienić zwracaną wartość z List na Set)
   2.2 Zrobić standaryzację po stronie testu, czyli albo jak jest tu już napisane posortować, albo zmienić List na Set i porównać te zbiory mając wywalone na kolejność.

Który z powyższych punktów opisuje twój problem?

Żeby osiągnąć wszystkie te elementy, sam widzisz - nie mogę przywiązać testów do implementacji, co znaczy że nie mogę ani parsować outputu w testach, ani pisać osobnych asercji pod różne systemy plików. Rozumiem, że jeśli nie umiesz pisać dobrych testów, oraz masz problem ze zrozumieniem natury tego tematu, łatwo Ci rzucać takie oskarżenia, dziękuję za podzieleniem się opinią.

Ale to ty masz problem z napisaniem tego testu. Jeżeli Riddle ma problem ze spełnieniem Riddle Test Principles, to ciężko będzie udowodnić, ze winę za to ponoszą ludzie który próbują odpowiedzieć na zadane przez Riddle pytanie. Może warto się przyjrzeć elementom tej układanki?

@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?