Tester kontra live: różnice w kodzie bota, przez które wynik się rozjeżdża

W skrócie: kod bota może zapytać, czy działa w Testerze (stała MQL_TESTER), i zachować się inaczej. Czasem to potrzebne, częściej to źródło wyników, których na koncie nie powtórzę. Moja zasada: zero rozgałęzień dotyczących zachowania handlowego, różnice wolno mieć tylko w rzeczach, których Tester technicznie nie obsługuje.

Skąd bierze się pokusa

Tester nie jest kopią terminala. Nie ma w nim panelu, maili, plików wymiany z innymi programami ani zmiennych globalnych przeżywających restart. Autor bota widzi to szybko: funkcja, która w teście nic nie robi albo spowalnia przebieg, dostaje warunek “jeśli to Tester, pomiń”. Do tego momentu wszystko jest w porządku.

Kłopot zaczyna się, gdy ten sam warunek trafia do logiki handlowej. Przykłady, na które łatwo się złapać: inny interwał sprawdzania trailingu w teście, “uproszczone” liczenie spreadu, pominięcie filtra wiadomości, bo kalendarz nie działa. Test wychodzi ładny, bo bot w nim jest innym botem niż ten na koncie.

Co różni oba tryby z natury

Bez żadnego kodu po stronie autora różnią się:

• Dane. Świece M1 z historii albo tiki generowane lub realne. Spread ze świec bywa nierealny, o czym piszę w artykule o spreadzie w backteście.
• Czas działania. W teście czas to czas z danych. Timer idzie według czasu symulowanego, a nie zegara ściennego.
• Wykonanie zleceń. Test zatwierdza zlecenie od razu, bez poślizgu i bez odrzuceń z powodu odległości od ceny czy przerwy w notowaniach.
• Środowisko. Brak innych botów na koncie, brak ręcznych zmian z telefonu, brak restartu terminala w środku.

Tych różnic nie usunę. Mogę je tylko znać i dopisać do nich poprawkę przy interpretacji wyniku.

Czego nie robię w kodzie

Przy bocie z filmu, którego test opisałem w artykule o OHLC kontra tiki, wynik zależał od tego, jak często bot sprawdzał pozycję. Z tego wyniosłem regułę zapisaną w zasadach repo: przesunięcie stopu na wejście i trailing sprawdzam raz na minutę, z bloku nowej minuty w obsłudze tików, tak samo w Testerze i na koncie. Nie z timera, nie z innym interwałem w teście. Rozgałęzienie “w Testerze co świecę, live co sekundę” daje dwa różne boty, więc porównanie traci sens.

Ta sama zasada działa w odwrotną stronę. Nie dopisuję w teście niczego, co poprawia wynik, i nie wyłączam w teście niczego, co go pogarsza.

Gdzie różnica w kodzie jest uzasadniona

Zostawiam ją wyłącznie przy funkcjach pomocniczych:

• stan dzienny trzymany w zmiennych globalnych terminala (dzienny limit, licznik) w Testerze jest wyłączony, bo każdy przebieg zaczyna od zera i zmienne mieszałyby przebiegi,
• powiadomienia, maile i komunikacja z panelem,
• rysowanie na wykresie, które w optymalizacji tylko kosztuje czas,
• zapis plików raportu.

Test na tym zyskuje, a decyzja o wejściu i wyjściu pozostaje identyczna. Kontrola jest prosta: po zmianie w tych miejscach ten sam przebieg testu musi dać tę samą listę transakcji.

Jak sprawdzam, że bot jest jednym botem

1. Grep po stałej trybu w kodzie bota i w bibliotece. Każde trafienie opisuję: czy dotyczy decyzji handlowej, czy tylko pomocniczych funkcji.
2. Ten sam odcinek dwa razy: test na świecach i test na tikach z tym samym ustawieniem. Duża rozbieżność liczby transakcji wskazuje na logikę zależną od tików, a nie na rozgałęzienie, ale wiem, gdzie szukać.
3. Tydzień real kontra test. Biorę konkretny tydzień z konta, uruchamiam test na tych samych dniach i porównuję listę transakcji, a nie sumę. Różnice w czasie wejścia o kilka sekund to norma. Brak transakcji po jednej ze stron to temat do rozkładania na części.
4. Po każdej zmianie biblioteki wspólnej dla wielu botów powtarzam test regresyjny, bo rozgałęzienie ukryte w bibliotece dotyka wszystkich.

[DO UZUPEŁNIENIA: własny przypadek, w którym wynik live odbiegł od testu i okazało się, że winny był kod bota, nie dane]

Checklista

• Sprawdziłem w kodzie bota i bibliotece, gdzie występuje rozgałęzienie “Tester / nie Tester”.
• Żadne z nich nie zmienia warunków wejścia, wyjścia, ryzyka ani częstotliwości sprawdzania pozycji.
• Przesunięcie na wejście i trailing działają z tego samego miejsca w obu trybach.
• Wiem, które funkcje są wyłączone w Testerze (stan dzienny, powiadomienia, panel).
• Porównałem listę transakcji testu i konta z tego samego tygodnia.
• Po zmianie biblioteki powtórzyłem test przed i po.

Powiązane

• Spread w backteście: świece M1 kontra tiki
• OHLC kontra prawdziwe tiki
• Lista transakcji zamiast sumy: diagnoza regresji
• Bot nie otwiera pozycji - 15 przyczyn
• Pojęcia z artykułu: słowniczek, skorowidz

Ostrzeżenie: handel CFD i forex wiąże się z wysokim ryzykiem utraty kapitału. Artykuł ma charakter edukacyjny i nie jest rekomendacją inwestycyjną.