Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:npf8j8$qj8$1@node1.news.atman.pl...
> Scenariusze które pokazują że dla takich danych wejściwych funckja ma dać
> takie dane wyjściowe. Przykład liczenia CRC jest wręcz ksiązkowym
> problemem dla unit testów. Unit testy są zywym kodem który mozna uruchomic
> i debugować jeśli coś nie działa.

Ok rozumiem, ale oni napisali by te unit testy pod C# i chcieli abym ja to
odpalił, a ja nigdy nic z C# do tej pory.
A ja im dostarczyłem źródło tego crc w C++, tylko oni "Nie pamiętam C++" i
dostarczyłem też działający program, który nawiązywał komunikację z
urządzeniem i wypisywał na ekranie każdą ramkę w postaci samego rozkazu i
potem ujętego w zaszyfrowanej ramce i również każdą odebraną ramkę i
wyłuskany z niej rozkaz.

>
> Nalezy w takiej sytuacji napisać unit testy które emulują urządzenie (tzw.
> mocki). Oczywiście zdaje sobie sprawę że to jest mało sensowna rada
> ponieważ zazwyczaj kod 3-rd party jest żenujacej jakości i unit testów nie
> da się na nim odpalić.

Musiałbym kiedyś raz z kimś przez takie działanie przejść, abym mógł
powiedzieć że dokładnie rozumiem co masz na myśli. A tak to rozumiem tylko
mniej więcej.

> Nie zmienia to jednak faktu że tak to należy zrobić książkowo. Czy Twój
> kod taki jest - nie wiem. Spodziewam się że nie skoro prosza o pomoc kogoś
> z drugiej strony.

Mój program jakby mieli Buildera 2010 to po prostu mogliby go kompilować i
debuggować.
Nie do końca rozumiem, jak oceniasz jakość kodu. Moim celem było napisanie
działającego przykładu. Procedury celowo nie są uniwersalne, tylko dokładnie
do tego co jest w przykładzie potrzeba bo takie według mnie łatwiej
zrozumieć. Sposób sterowania komunikacją też absolutnie nie nadający się do
praktycznego zastosowania, ale taki, aby jednym rzutem oka było widać co się
po kolei dzieje.
Mogę Ci go wysłać do obejrzenia, ale nie wiem czy to ma sens i czy masz na
to czas.

> Ale dlaczego podejrzewasz - jesli Twoje urządzenie prawidlowo odpowada na
> ciąg przez nich wysyłany to dlaczego masz to diagnozować?

Nie zrozumiałeś. Komunikację rozpoczyna urządzenie wysyłając ramkę z liczbą
losową do serwera. Ramka ma crc, ale nie jest podpisana.
Serwer ma odpowiedzieć ramką z drugą liczbą losową i podpisem CMAC obu liczb
losowych.
Oni (serwer) wysyłali ramkę na którą nie dostawali już odpowiedzi - czyli
nie dostawali żadnej odpowiedzi na swoje działania.
Gość najpierw mi podesłał samą wysłaną przez nich ramkę abym sprawdził
dlaczego urządzenie nie odpowiada. Gdybym wpadł na to, że to może crc to bym
sprawdził, ale sądziłem, że crc to musieli przecież sprawdzić (bo mają tę
pierwszą ramkę) więc byłem absolutnie pewien, że błąd jest w CMAC i mu
napisałem, że muszę mieć też tę ramkę na którą on odpowiada abym znał liczbę
losową akurat z tej transmisji. Nie miałem gotowca, aby z tekstu (HEX)
odczytywać bajty (a sądziłem, że może będę to musiał wiele razy robić) więc
musiałem to napisać i się zdziwiłem, że CMAC mają dobry. No to sprawdziłem
jeszcze crc i napisałem, że tu mają błąd. Jak mi gość napisał (w liczbie
mnogiej), że oni przetłumaczyli moje źródło crc na C# i nie widzą błędu i mi
to w C# przysłał to w sumie wskazując błąd odpisałem, że "ręce człowiekowi
opadają".

Pewnym problemem jest to, że jak puszczą komunikację urządzenia z moim
programem to mają wszystko wypisane bajt po bajcie na ekranie (i w pliku
trace), ale jak próbują sami się komunikować to transmisja już jest inna, bo
urządzenie wyśle inną liczbę losową. Według mnie oni powinni (nie mając
Buildera) na podstawie mojego trace zobaczyć, czy wyjdzie im dokładnie taka
sama odpowiedź jak mój program odpowiadał. Ale oni jakoś tak woleli do
wszystkiego podchodzić chaotycznie i metodą prób i błędów.

> Niech sobie napiszą emulator/mock i testują u siebie.

Zależy nam zawsze aby pomóc (szczególnie jak wiemy, że mają nóż na gardle -
bo ten obiekt jakoś miał coś z funduszami unijnymi i odbiór nie mógł być
opóźniany bo coś tam) więc nawet jak uważałem, że to nie powinien być mój
problem to starałem się pomóc ile potrafię.

>> Masz na myśli tamtą firmę, czy naszą? My chcemy dostarczać ludziom jak
>> najbardziej przydatne im informacje, ale nie przekraczając swojego
>> poziomu kompetencji.
>
> Dostarczasz dokumentacje. Zadaniem firmy softwareowej która implementuje
> ten protokół jest napisać unit testy które są zgodne z ta dokumentacją.
> Nie zrobili tego zapewne.

Na pewno nie zrobili bo od dostarczenia dokumentacji (kilkadziesiąt stron)
to tych prób minął jeden dzień. Wyjątkowa sytuacja.

>> Ja do tego przykładu użyłem jednego obiektu z biblioteki dostarczonej
>> razem z Builderem 2010, ale słyszałem, że nie za bardzo jest ona
>> optymalna, więc zakładałem, że prawdziwi programiści obsługują TCPIP
>> bezpośrednio funkcjami systemu operacyjnego (czego ja nie ogarniam).
>
> Nie. Zdefiniuj wydajność. Każdą biblioteke mozna źle uzyć i narzekać na
> wydajność. Builder ma swoje za uszami, ale że nie wyciąga w sieci ile
> fabryka dała to nie uwierzę.

To jest biblioteka INDY, napisana przez kogoś innego i dołączona do
Buildera.
Opinię usłyszałem od kogoś, kto orientuje się w tych tematach znacznie
lepiej ode mnie, ale dokładnie co i jak to nie powiem.

> "Lepiej" zalezy od zastosowania i umiejętności. Poleciłbym Clojure gdyby
> było dla niego zastosowanie. Tak samo Prologa. Wszystko zalezy od tego co
> chcesz zrobić. jak nie wiesz to ... Python, Java, C#.

Gdy poznawałem Prologa to akurat miałem potrzebę napisania assemblera 51-ki
więc pierwsza wersja mojego assemblera była w Prologu i to jest chyba
przykład najgorszego dobrania narzędzia do celu :).
Potem napisałem wszystko od nowa, a o Prologu zapomniałem całkiem.
P.G.