Niepokojąca sugestia o błędzie w obsłudze SSL w produktach Apple

Stawiam na świadomy 'debug’ i zapominalstwo programisty. Od 7 lat pracuję jako developer i nie takie kwiatki widziałem.

Klasyczna sytuacja, gdy ktoś chce sprawdzić działanie instrukcji występujących PO warunku, ale nie chce mu się doprowadzać do sytuacji, gdy warunek jest spełniony – wtedy robi się taki myk, że zawsze, niezależnie od rezultatu, instrukcja zwraca 'true’, by zobaczyć, co się dzieje dalej.

Przykład praktyczny:

kod 'produkcyjny’:

function costam(dane_wejsciowe) {
if (dane_wejsciowe == true) {
return 'ok’;
} else {
return 'error’;
}
}

Powiedzmy, że robimy jakąś funkcjonalność, zależną od zwróconego z f-cji costam() rezultatu 'ok’, ALE aby to uzyskać, musimy spełnić warunek, by 'dane_wejsciowe’ były równe 'true’.

Dodajemy sobie więc linijkę:

function costam(dane_wejsciowe) {

/* dodany na sztywno rezultat zwracany przez f-cję, niezalezny od warunku wejsciowego */
return 'ok’;

if (dane_wejsciowe == true) {
return 'ok’;
} else {
return 'error’;
}
}

To powoduje, że f-cja costam() ZAWSZE zwróci nam 'ok’.

Pracujemy sobie dalej nad naszą funkcjonalnością, po czym commitujemy zmiany. Oczywiście zapominamy usunąć nasze „return 'ok'”, co powoduje, że aplikacja działa tak, jakby 'dane_wejsciowe’ zawsze miały wartość 'true’ w momencie wywołania f-cji costam().

To oczywiście tylko przykład, ale mniej więcej tak to wygląda w praktyce (spróbujcie kiedyś zaimplementować jakąś funkcjonalność w dużej aplikacji, która to funkcjonalność działa w zależności od spełnienia kilku warunków w innych miejscach i ZA KAŻDYM RAZEM być zmuszonym do doprowadzenia aplikacji do takiego stanu, by mógł wykonać się Wasz kod. Szybciutko w waszym kodzie pojawią się takie myki :)

Oczywiście to nie jest zalecany sposób. Można np. próbować mockować dane wejściowe tak, by uzyskać właściwe rezultaty. Ale często gęsto warunki wejściowe zależą np. od odpowiedzi usług zlokalizowanych w zewnętrznych serwisach, do których na przykład nie macie dostępu ze swojej maszyny developerskiej (a przetestowanie jest możliwe jedynie na maszynach mających kontakt ze światem zewnętrznym, np. na serwerach UAT – user acceptance test, czy CIT – continous integration test).

No i co jeszcze bardzo ważne – takie rzeczy powinny wyjść na etapie testów (dlatego właśnie pisanie testów jest tak istotną kwestią, ale jak wiemy, metodologie wytwarzania oprogramowania sobie, a praktyka sobie). Choć to też nie jest regułą, bo testy też mogą być napisane błędnie i nie wychwycić takich niuansów (no bo przecież f-kcja costam() działa ;) )