Robot może pobierać dane z API na demo, a w testerze nie otrzymywać tych samych odpowiedzi. To nie musi oznaczać awarii serwera. Najpierw sprawdź dostępność funkcji w środowisku testowym, potem sposób zachowania historii. Pobranie dzisiejszej wartości i przypisanie jej wcześniejszym decyzjom tworzy inny test. Poniżej zbudujesz jawny model odtwarzania wersji, który rozróżnia późniejszą rewizję i brak danych, bez łączenia się z zewnętrznym API.
Dlaczego działający WebRequest nie wystarcza do backtestu?
Dokumentacja MQL5 wskazuje, że WebRequest nie może być wykonywany w Strategy Tester. Dodanie adresu do dozwolonych URL terminala nie zmienia tej właściwości testera. Oddziel problem niedozwolonej funkcji od braku połączenia, błędnej autoryzacji i odpowiedzi, którą otrzymujesz podczas zwykłej pracy EA.
Załóżmy, że reguła potrzebuje zewnętrznego odczytu gospodarczego. Nie zamieniaj nieudanego pobrania na liczbę zero. Zero może być prawidłową wartością danych, podczas gdy błąd oznacza brak wejścia do oceny. Samo zastąpienie WebRequest plikiem też nie wystarczy: plik może zawierać najnowsze rewizje, których robot nie znał w badanej chwili.
Najpierw zdefiniuj, czego potrzebuje strategia: nazwy obserwacji, wersji, wartości i chwili dostępności. Nie wiąż warunku wejścia bezpośrednio z pobraniem HTTP. Poradnik EA rozdziela dane, decyzję i wykonanie; tutaj rozwijamy tę pierwszą warstwę. Zmiana adaptera nie powinna po cichu zmieniać znaczenia informacji.
Jak oddzielić adapter online od odtwarzania offline?
Adapter online obsługuje odpowiedź dostawcy i zapisuje jej znaczenie. Adapter testowy wybiera zachowany rekord dostępny dla chwili decyzji. Oba przekazują logice ten sam rodzaj wyniku: poprawna wartość, jawny brak lub błąd. To własna propozycja organizacji kodu, nie gotowy robot ani obietnica zgodności z każdym API.
Zachowuj surową odpowiedź poza plikiem przygotowanym do testu. Zanotuj źródło, wersję schematu, czas odczytu i sposób ustalenia dostępności. Okres, którego dotyczy obserwacja, nie jest godziną jej poznania. Jeżeli znasz wyłącznie datę wersji, nie dopisuj precyzyjnej godziny. Archiwum o dokładności dziennej nie potwierdza samo momentu dostępności wewnątrz dnia.
FRED opisuje okresy real-time odróżniające to, co jest znane obecnie, od danych znanych w przeszłości. To przykład mechanizmu wersji, nie uniwersalne API dla rynku forex. Daty vintage nie zamieniają się automatycznie w dokładne znaczniki publikacji UTC. Chronologię konkretnego dostawcy musisz ustalić osobno.
W MQL5 FileOpen działa w określonym obszarze plików, także podczas testowania. Nie zakładaj, że względna ścieżka wskazuje ten sam folder co w zwykłym terminalu. Sprawdź powodzenie otwarcia i odczytu. Brak pliku ma dać rozpoznany brak danych, a nie pustą tabelę traktowaną jako kompletną historię.
Którą wersję wolno podać wcześniejszej decyzji?
Własna historia trzech odpowiedzi
Przyjmij fikcyjną obserwację GDP-model i jedną umowną datę: 1 października 2026 roku. Nie są to publikacje PKB ani dane rzeczywistego endpointu. Wszystkie chwile należą do UTC. availableAt określa, kiedy dany rekord udostępniamy naszemu modelowi; nie wyznacza czasu wykonania zlecenia.
| availableAt | revision | value |
|---|---|---|
| 2026-10-01T12:00:00Z | initial | "1.0" |
| 2026-10-01T13:00:00Z | revised | "1.4" |
| 2026-10-01T14:00:00Z | unavailable | null |
O 12:30 ostatnią dostępną wersją jest 1,0. O 13:30 jest to 1,4. O 14:30 najnowszy dostępny rekord ma null, więc raport pokazuje brak wartości. W tym modelu nie cofamy się po starszy odczyt 1,4 i nie tworzymy z braku liczby zero.
Wersja dostępna wtedy, nie dzisiaj
Przy fikcyjnym warunku „wartość ponad 1,2” ocena o 12:30 byłaby fałszywa. Wstawienie późniejszego 1,4 dałoby przeciwny wynik, mimo że ceny w backteście pozostałyby identyczne. To test dostępności wejścia, nie rentowności strategii. Narzędzie poniżej wybiera rekord, ale nie oblicza sygnału ani zysku.
Jeżeli strategia ma korzystać z ostatniej znanej wartości przy braku nowych danych, zaprojektuj to jako osobną politykę: określ dopuszczalny wiek i powód użycia starszego rekordu. Nie dopisuj takiej polityki dopiero po korzystnym wyniku. Nasz wariant jawnego null celowo jej nie stosuje; uczy rozdzielenia wartości od dostępności.
Co porównasz w lokalnym replayerze?
Wklej obiekt JSON z version równym liczbie 1 oraz tablicą events. Każdy rekord ma cztery pola: availableAt, observation, value i revision. Pierwsze pole wymaga pełnego zapisu YYYY-MM-DDTHH:mm:ssZ, bez ułamków sekundy i innych przesunięć. observation i revision są tekstem. value to tekst liczbowy z kropką albo null; zapis tekstowy zachowuje znaki bez konwersji na Number. Limit wynosi 1–200 zdarzeń i 64 KiB JSON. observation ma do 128 znaków, revision do 64, a value do 128.
Odtwórz informację dostępną w chwili decyzji
Własny przykład dydaktyczny. Analiza działa lokalnie w przeglądarce: nie łączy się z rachunkiem ani API, nie wysyła wpisanych danych i nie zapisuje ich trwale. Nie wpisuj haseł ani danych osobowych.
Osobno podaj chwilę decyzji decisionAt w tym samym formacie UTC. Model wybiera najpóźniejszą wersję danej obserwacji, której availableAt nie przekracza decyzji. Przed pierwszym rekordem nie ma dostępnej wartości. Dwa rekordy tej samej obserwacji z identycznym czasem są niejednoznaczne i odrzucane, zamiast rozstrzygania kolejnością wklejenia. Nazwa revision nie jest liczbą określającą chronologię.
Ćwiczenie działa lokalnie na wklejonych zdarzeniach. Nie pobiera publikacji, nie korzysta z kluczy API i nie potwierdza dat dostawcy. Prawidłowy JSON nie oznacza prawdziwego archiwum. Jeżeli czasy wpiszesz z pamięci albo wszystkie późniejsze rewizje oznaczysz pierwotną datą, poprawny algorytm odtworzy błędne założenia. Zachowaj dokumentację pochodzenia każdego rzeczywistego zbioru.
Dokumentacja testera rozróżnia pliki i środowisko agentów od terminala. Przy równoległych przebiegach korzystaj z ustalonej kopii danych; nie nadpisuj jej bieżącą odpowiedzią w trakcie badania. Do manifestu przebiegu dopisz identyfikator faktycznie zachowanej wersji, nie tylko nazwę endpointu.
Zasady łączenia informacji po czasie rozwija backtest w Pythonie, a rewizje publikacji poradnik kalendarza. Odtworzenie danych nie odtwarza automatycznie wykonania: ceny Bid/Ask, koszty, wolumen i odpowiedzi serwera pozostają osobnymi elementami. Zacznij od porównania kilku decyzji bez składania transakcji.
Co zrobić przed oceną wyniku takiego robota?
- Spisz kontrakt danych i rozdziel adaptery online oraz offline. Zachowaj surowe odpowiedzi, opis obserwacji i podstawę ustalenia czasu dostępności. Brak historycznej wersji oznacz jako ograniczenie, zamiast podstawiać dzisiejszy wynik pod dawną datę.
- Prześledź jedną fikcyjną obserwację przed pierwszą wersją, między publikacją a rewizją oraz po jawnym braku. Porównaj wybrane rekordy z tabelą. Sprawdź równość granicy czasu i konflikt dwóch zapisów, zanim użyjesz algorytmu w większym badaniu.
- W testerze potwierdź odczyt właściwego pliku i reakcję na brak danych. Zapisz wersję zbioru z raportem. Dopiero po wyjaśnieniu różnic kontroluj sygnały, wykonanie i koszty; rzetelne odtwarzanie wejść nie stanowi dowodu przyszłej rentowności.
Sprawdź, czy rozumiesz
Jedno krótkie ćwiczenie
Około 3 min · możesz spróbować ponownie
GDP-model ma 1,0 dostępne o 12:00 UTC i rewizję 1,4 o 13:00. Którą wartość wybiera nasz model dla decyzji o 12:30?
- 1,4, bo to ostatecznie poprawiona wartość.
- 1,0, czyli ostatnią dostępną wersję.
- 0, bo tester nie obsługuje WebRequest.
Sprawdź odpowiedź i wyjaśnienie
1,0, czyli ostatnią dostępną wersję.
Tak. Rekord 12:00 jest dostępny przed decyzją; późniejsza rewizja nie zmienia wejścia wcześniejszej oceny.