How to Backtest an EA That Uses Three Timeframes in Strategy Tester? - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Don't pull out your "resume/CV" as proof. If I would have to give out mine, I would have you beat.
The only thing that counts here is the skill and knowledge about MQL5, MetaTrader 5 and it's Strategy Tester.
I know exactly what I am stating because I personally developed an EA in 2023 for a customer, with single source for both MQL4 and MQL5, with almost the same exact requirements you have described—a multi-time-frame ZigZag and Elliot Wave Analysis with trading dependant on multiple time-frames. It was a big project. And, I can tell you that the Strategy Tester (both on MT4 and MT5) perfectly synchronised all the data without any issues what-so-ever.
On MetaTrader 4 it handled all the synchronisation 4066/4073 errors, and on MetaTrader 5 it organised the data as documented ... Documentation on MQL5: Timeseries and Indicators Access / Organizing Data Access.
Besides this project, I personally trade my own EAs, some of which are multi-time-frame and multi-symbol, and they ALL exhibit the same behaviour in both the Strategy Tester and on live trading. There are no issues with synchronisation in the Strategy Tester, when the code logic is properly written.
EDIT: In the Strategy Tester I always test against tick data (real or virtual), and never on any other modelling mode.
So you have the following choice ...
What I actually need is to see the lower timeframe on the lower chart and the higher timeframe on the higher chart, so I can visually analyze the patterns and price actions directly on those charts.This way, I can see how everything is fitting together, just like how the price action is displayed on the current chart, without needing a separate window for the indicator.
So, my goal is to have everything running directly on the charts for each timeframe (current, higher, and lower) in real-time to observe how the patterns and price action are aligning. This allows me to visualize everything in sync, as shown on the current chart.
Indeed, I can retrieve information from multiple charts, and that part works fine. However, the real challenge arises when trying to test multiple Expert Advisors that interact with each other, or even testing the same Expert Advisor in different instances, all running on the same tick simultaneously. Unfortunately, this capability is currently limited, and it's not possible to conduct such tests effectively within the strategy tester at the moment.
To be honest, I don't get the point of making 3 expert advisors communicate with each other, but I do see a purpose in making 3 indicators communicate with each other (in one EA). You have options like creating synthetic charts or different coloured drawings that you could layer (I have limited knowledge on synthetic charts in this framework, I know that you can attach indicators to them, but don't know if they can be instantiated in the visual strategy tester).
I have no issues with the testing, everything works fine, and the results are impressive, as I believe you've seen a picture of the backtest. There are no errors.
If I give you one of my experts that writes in terminal global variables, or if you give me one of your experts that also writes in terminal global variables, we can both read them and integrate the experts.
Everything would work perfectly fine. However, the problem is that we currently can’t test this setup as it stands. To use the strategy, all the expert codes need to be mine, or I would have to rewrite the code to integrate your expert and mine into a single code. That’s outside of the integration between systems.
So, we know how to perform integration, and the method exists, whether it’s through global variables, files, or others. But we can’t test the integration without adjusting the code to be compatible with the testing of that integration.
Instead of us attacking each other back and forth, we should take advantage of each other’s expertise, find a solution that moves us forward, and helps us benefit from everything built inside one thing, for the better.
By the way, I’ve found a potential solution for the testing issue and I’m currently testing it.
This approach works perfectly in backtesting with no errors, producing good results. However, for live trading, I have taken things a step further by running separate instances of the EA on different charts:
This allows the current timeframe on each chart to act as the lower or higher timeframe relative to the other, enabling the same deep calculations to be applied at each level. The EAs communicate using global variables, refining wave structures and synchronizing critical data between timeframes. This enhancement has significantly improved performance.
Unfortunately, the strategy tester does not allow testing all three instances together, which is the main limitation I am facing. If you have any ideas on how to overcome this within the tester, I would greatly appreciate your insights.
The problem you describe now is very different to what you initially described in your first post. You did not mention anything about wanting to run 3 EAs simultaneously in the Strategy Tester. Obviously that is not possible.
You can however, design a class to fully encapsulate your EA's functionality, so that you can then instantiate multiple objects of it with different time-frame parameters, effectively running 3 EAs inside one, and being able to run it in the tester. And you will not need to use the Global Terminal Variables either.
However, if you require running 3 EAs, then your design is very inefficient, and you need to seriously consider refactoring your design.
To be honest, I don't get the point of making 3 expert advisors communicate with each other, but I do see a purpose in making 3 indicators communicate with each other (in one EA). You have options like creating synthetic charts or different coloured drawings that you could layer (I have limited knowledge on synthetic charts in this framework, I know that you can attach indicators to them, but don't know if they can be instantiated in the visual strategy tester).
To clarify, my approach involves having one Expert Advisor that works across all three timeframes, initially processing the data from all three and then focusing specifically on the current timeframe. This allows it to fine-tune and become highly accurate. Additionally, it uses both the smaller and larger timeframes to ensure the analysis is comprehensive.
So, when I run three instances of the EA, each focused on its respective timeframe, the system starts to provide a more complete picture. For example, if I'm on the 5-minute chart and the best solution for that timeframe is achieved, the EA on the 15-minute chart will read data more accurately based on the improved 5-minute data, and similarly for the higher timeframes.
I initially thought of drawing the bars from the other timeframes on the same chart, but that approach turned out to be very complicated. Synthetic charts don’t rely on traditional market data; instead, they’re based on formulas and algorithms that simulate the market in a specific way. However, what I need is straightforward: I want the Expert Advisor to work on the smaller and larger timeframes, fetching data from them after they’ve been refined. If these timeframes were visible simultaneously, the process would be much more efficient and insightful.
The problem you describe now is very different to what you initially described in your first post. You did not mention anything about wanting to run 3 EAs simultaneously in the Strategy Tester. Obviously that is not possible.
I have already structured my code in a modular way using classes and methods, ensuring that each component is independent and reusable. The Expert Advisor itself is implemented as a class in Metatrader, and each instance is allocated its own memory space. My approach is to run each instance on a specific time frame, making each one fully independent while allowing communication between them.
This setup eliminates the need to restart charts when modifying parameters, as each instance operates autonomously yet interacts with the others.
I have already tested the multi-timeframe approach, and it works perfectly. Each instance operates on its own timeframe while interacting dynamically with both the higher and lower timeframes. This means that on the current timeframe, the EA refines its data, while the lower timeframe provides more precision, and the higher timeframe offers broader context.
Now, imagine three traders: one running the EA on M5, another on M15, and a third on H1. Each has fine-tuned their settings to achieve the most accurate wave patterns for their respective timeframe. In a live environment, they all benefit from each other’s analysis through inter-expert communication using Global Terminal Variables.
The issue arises in the Strategy Tester. There’s no built-in way to test this interaction unless I modify the code to fit what the Tester allows. I have other systems I want to integrate into the same backtest—like harmonic pattern scanners and candlestick pattern detection—and they all communicate via Global Terminal Variables. In live trading, they work seamlessly together.
However, to backtest this interaction, I would have to merge them all into a single codebase. That’s not the right approach for modular system development, and it’s not how real-world applications should be built.
The problem becomes even more complex if I have external code written in other languages, which I call through DLLs. Despite everything running within the same terminal, the Strategy Tester doesn’t provide a way to simulate this cross-expert interaction naturally.
What works in live trading should also be testable in the Strategy Tester without requiring artificial workarounds. A proper backtesting environment should allow us to simulate the exact live conditions instead of forcing us to restructure the code just to fit the testing limitations.
My ultimate goal is to reach a point where I can say: 'Mr. Fernando, I really like your EA, and I want to integrate it with mine. Could you simply output certain key results as Global Variables so my EA can use them?'
When we can achieve this level of seamless integration—without needing you to go back and modify an EA you built years ago, or me having to rewrite parts of my old systems just to make them compatible with the strategy tester constains—then that’s the ideal solution.
This is the reality of modern development: building modular, independent components that can communicate efficiently without requiring constant rewrites or deep code reviews just for integration.
We can easily achieve this in a live environment, but we can't properly test it in the Strategy Tester. This means we'll always have some level of uncertainty about the results.
Without a way to simulate this multi-EA interaction during backtesting, we’re left with a gap between theory and practice. The live system might work perfectly, but without rigorous testing, we can't be 100% confident in the performance before deployment.
This is the real challenge: finding a way to test EAs that communicate with each other, just as they would in a live terminal.
Look at the chart, and you'll see that the Strategy Tester is working fine, performing the retracement, switching to the smaller time frame, scanning the internal waves, counting them correctly, and then bringing the result back to the current chart. Everything is working well in the tester.
What I'm asking for now is much further along—it's about the refinement and integration phase. Just like they work seamlessly in live, they need to function the same way in the test environment.
Also, if you notice, it's version 34, meaning I've been working on it for a long time, making significant improvements to perfectly mimic the real-world scenario.
@Ahmd Fwzy Hamd ʿLy Albshbyshy
It seems that no matter how we try to address your "issues", you come back with some new more complex scenario (which was not mentioned in preceding posts), and complain that the Strategy Tester is incapable of handling it.
In the first post, none of your complaints were valid, and as you increased your complexity (attempting to prove us "wrong"), we tried suggesting solutions or work-arounds. However, as you kept absurdly increasing the complexity, at some point it become obvious that you simply don't want to accept that the Strategy Tester was not designed to simulate the "universe", but was designed for testing specific requirements that most regular traders would need.
So, here is my final solution that will sove everything for you ... develop your own Strategy Tester.
I meant from the beginning that I want to test the EA itself as if it were a separate program running on multiple charts.
and i stated that in the first post "
Key Problem:
This is the method I have always used in development throughout my career. However, I may not have expressed it clearly because I am not used to the single-threaded testing system, which forces me to adapt my code to the tester instead of the tester adapting to my code.
Secondly, I must have a definitive solution for performing integration testing between legacy and new programs. As a developer, you know that you might have written a program years or even months ago and don’t remember its internal logic, but you do know how to extract its output and input parameters so that other programs can use it—for example, via XML.
Just as I can make multiple independent programs communicate in live trading, I should also be able to test their interaction in the Strategy Tester.
Most modern testing environments support this approach, allowing different components to interact in a simulated environment without forcing developers to merge them into a single codebase.
For example, in other testing frameworks:
-JUnit (Java) – Can test separate modules while ensuring they interact correctly.
-PyTest (Python) – Allows mocking external dependencies and testing integration.
MetaQuotes should provide a backtesting solution that enables multiple EAs to communicate exactly as they do in live trading, ensuring accurate and realistic results.
Until then I have found a workaround. It’s not the ideal solution, but I’ll proceed with it for now
May I ask why you need multiple EAs to communicate information? What is the purpose of this?
Thank you for your input. I’ve actually found a workaround for the issue, although I recognize it’s not the ideal solution. I run the Expert Advisor on three separate charts, each trading on different timeframe, to see the behavior on all of them. Each instance has its own settings, and I review the results to ensure each one is optimized for its specific timeframe. However, the concept is simpler than it seems.
I have other Expert Advisors that export global variables and write results to CSV files. I use these independent programs to confirm each other’s results. For example, I have an Expert Advisor that detects candlestick patterns on specific timeframes, and another that manages trailing stops for specific ticket numbers and they work together seamlessly, but the integration can't be tested and that’s just one of the cases.
In the Expert Advisor I mentioned, I’ve set up three instances to run in the Strategy Tester across three different timeframes. The setup includes advanced money management and other complex features that took months to build. However, this doesn’t prevent me from using other systems I’ve built in a different Expert Advisor via integration, either through global variables or files.
Unfortunately, the Strategy Tester doesn't allow for testing this type of setup. That’s the issue I’m facing. The testing scenario needs to be able to simulate real-world production scenarios. Since multiple different EAs are working together and communicating without modifying their code in the production environment, it should be possible to test that as well.
This is exactly what the test environment should handle, and it’s something I’ve been accustomed to throughout my professional career. The ability to test different programs communicating with each other without requiring constant code modifications is crucial, and this is a standard approach in most testing environments I’ve worked with.
That's why, considering the problem of testing the same EA across multiple charts simultaneously and allowing them to improve each other, it’s solved as long as I’m still working on coding it and haven’t finalized it yet. However, this becomes a major issue when integrating other closed programs that can’t be opened or modified. Or when integrating other programs that I didn't write myself, but have asked their creators to output data for integration.
This is the nature of enterprise applications — programs integrate with each other to create larger systems. Once each program knows what it needs from the other, without needing to know the details of how the other works, it can function seamlessly. Each program focuses on delivering its required output and taking the necessary input without getting involved in the internals of the other.
And it’s not about reinventing the wheel just because the test environment doesn’t support it in its current form although the solution works perfectly fine in production.