Hello!

I am developing my own Visualizer and to test it I am also writing unit tests. A few tests require initialized Position objects. I would like to set the following properties of a Position object, but they appear to be read only:

- Shares
- NetProfit

There must be a way to set those properties, as WL does it somehow when PositionSizing.

Could you please help me finding a way how to set those properties?

Thanks
Konstantin

Hi Konstantin,

You can only "set" those properties by trading. That's why they are read-only in C#.

Hi Eugene,

OK.

I have all the information I need, like trades from my backtest, equity curve, Bars of symbols, etc., in CSV files. In my unit test I read all the information and I am ready to set the Position objects.

When you say "those properties are set by trading". How can I emulate that in my unit test?

Cheers
Konstantin

Trading happens inside your WealthScript strategy. This is the only supported way of affecting those properties.

Do you mean by calling e.g. BuyAtMarket()?

If yes, can I instantiate a Strategy outside of WL to use those Methods to create a set of Positions?

Right, by calling e.g. BuyAtMarket() in your Strategy. You may have your opinion on unit tests but if I may share mine after having developed about a dozen visualizers, you're overcomplicating the task. As to setting the read-only properties, you may have success using mocking technique (just don't ask me - I haven't used it):

http://www.typemock.com/unit-test-patterns-for-net#mock
http://stackoverflow.com/questions/2540146/how-do-you-create-a-unit-testing-stub-for-an-interface-containing-a-read-only-me

QUOTE:
If yes, can I instantiate a Strategy outside of WL to use those Methods to create a set of Positions?

Probably yes but since this is unsupported you would be completely on your own with this.

OK. Mocking seems to be the solution for now.

Thanks!

You're welcome.

I'm not sure if this helps, but I created this awhile back to load trades into a strategy.

CODE:
Please log in to see this code.

Panache,

Your approach doesn't support anything but BuyAtMarket. Why not simply use the full-blown solution which is available for years and is a one-liner to call?

Import real (historical) trades

QUOTE:
Why not simply use the full-blown solution which is available for years and is a one-liner to call?

This is really off topic, but since you asked, I'll explain.

First, I wasn't aware of the Import real (historical) trades. You guys have a tremendous knowledge base. Unfortunately, searching it is not all that easy. Some things are in the Quick Reference, some are in the User Guide, some are in the Programming Guide, some are in the Wiki and many are contained in the Forums. The result is that it is often easier to reinvent the wheel than to go looking for something, especially when you're not even sure what it's called.

This code was one of my early attempts to overcome what I consider a flaw in WealthLab -- the Data Range is used both to determine how much data to load and to measure many of the metrics in the Performance tab. (I know you guys disagree, and yes, you can load all data for a symbol, but if the Data Set contains a lot of symbols, each of which has a lot of data, it can take a long time to run.) Therefore, the one year Performance of a Strategy which is "all in" on the first day of the year will typically look better than a Strategy which takes many bars to get up and running.

This code was part of a dual Strategy. The first got the Strategy up and running and then saved the trades as of the end of the previous year. I then ran this code which began the year with those trades (having their beginning value on the open on the first day of the year) which allowed an accurate calculation of the Performance during the following year.

I have since found better ways to work around the problem. My current choice is to have a Strategy Parameter which determines the time for the Strategy to start trading. This allows me to load as much data as I need ahead of time. Some of the Performance metrics aren't applicable doing it this way, but I consider that an acceptable trade off.

Hi there!

I resolved my issue using the mocking technique. It was not straight forward. You can find the solution here:
C# Mock a Class With an Internal Property Setter