I'm writing a pretty complex strategy. It has about 30 individual source files so far and I'm only half-way finished. I'm using the technique I posted last week to allow me use different source files in my own structure. Unit tests are crucial for an application of this nature: it is financial in nature and contains a ton of math. Unit testing should be easy to do.... NinjaTrader makes great use of Interfaces for its classes.... So theoretically, I should be able to take an 'NinjaTrader.Data.IBar' interface, make my own "mock bar" object, throw it at my code and run some tests. Looks like a bar, acts like a bar, but doesn't need me to be connected to Ninja or FXCM to get it - I can test my code in isolation.
HOWEVER this cannot be done because you are running SecureCLI over your interfaces as well as your code. And any attempt to intialise a mock-type based on Ninjatrader.Data.IBar returns the following error:
The cctor part is a static constructor - which CliSecure is adding to the Intermediate Language on the interface. Therefore any time I try to make an instance of my own type which implements this interface, the static constructor is called - it tries do do its usual security stuff under the hood and fails.
If I did the same task from inside the indicator while running within Ninjatrader - with the same mock type, it works, in my own unit test project, it doesn't. The point of unit testing, and using interfaces for mocking types is so that we can write loosely coupled software separate from Ninjatrader that is able to interface with Ninjatrader.
There is absolutely NO gain whatsoever from CliSecuring interfaces. I can still look at them in reflector or Visual Studio Object Browser and can see the implementation - that's the point - interfaces should be transparent. Its how other 'things' interface with 'things'.
I was happy to hear from Dave the PM last week that NT has gone further with allowing development from within Visual Studio. But if you guys are really serious about getting highly-experienced programmer using your software to write great strategies then you need to go a lot further - unit testing is a crucial part of this and securing interfaces is so utterly pointless.
Furthermore, its good architectural design practice (and feel free to get your Solution Architect to contact me directly, because I am one) to have interfaces separate from implementation http://martinfowler.com/eaaCatalog/s...Interface.html for this exact reason - so that you can provide the interfaces to a third-party and let them write effective software based on these interfaces. The fact that NinjaTrader.Core.dll is 6 megabytes says it all.
I'm getting around this, but it is requiring me to make a whole load of new interfaces and eventargs identical to your own e.g ICandle - just so that I can write code without running Ninjatrader every 5 mins to test it.
Its not ideal. Could something be done please?
[Small test project attached which shows the problem]
HOWEVER this cannot be done because you are running SecureCLI over your interfaces as well as your code. And any attempt to intialise a mock-type based on Ninjatrader.Data.IBar returns the following error:
Test method IBarTypeInitProblem.Test.TestMethod1 threw exception:
System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: ptr
at System.Runtime.InteropServices.Marshal.GetDelegate ForFunctionPointer(IntPtr*ptr,*Type*t)
at <CliSecureRT>.InitializeThroughDelegate(IntPtr)
at <CliSecureRT>.Initialize()
at .cctor()
--- End of inner exception stack trace ---
at IBarTypeInitProblem.Test.TestMethod1()
System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: ptr
at System.Runtime.InteropServices.Marshal.GetDelegate ForFunctionPointer(IntPtr*ptr,*Type*t)
at <CliSecureRT>.InitializeThroughDelegate(IntPtr)
at <CliSecureRT>.Initialize()
at .cctor()
--- End of inner exception stack trace ---
at IBarTypeInitProblem.Test.TestMethod1()
The cctor part is a static constructor - which CliSecure is adding to the Intermediate Language on the interface. Therefore any time I try to make an instance of my own type which implements this interface, the static constructor is called - it tries do do its usual security stuff under the hood and fails.
If I did the same task from inside the indicator while running within Ninjatrader - with the same mock type, it works, in my own unit test project, it doesn't. The point of unit testing, and using interfaces for mocking types is so that we can write loosely coupled software separate from Ninjatrader that is able to interface with Ninjatrader.
There is absolutely NO gain whatsoever from CliSecuring interfaces. I can still look at them in reflector or Visual Studio Object Browser and can see the implementation - that's the point - interfaces should be transparent. Its how other 'things' interface with 'things'.
I was happy to hear from Dave the PM last week that NT has gone further with allowing development from within Visual Studio. But if you guys are really serious about getting highly-experienced programmer using your software to write great strategies then you need to go a lot further - unit testing is a crucial part of this and securing interfaces is so utterly pointless.
Furthermore, its good architectural design practice (and feel free to get your Solution Architect to contact me directly, because I am one) to have interfaces separate from implementation http://martinfowler.com/eaaCatalog/s...Interface.html for this exact reason - so that you can provide the interfaces to a third-party and let them write effective software based on these interfaces. The fact that NinjaTrader.Core.dll is 6 megabytes says it all.
I'm getting around this, but it is requiring me to make a whole load of new interfaces and eventargs identical to your own e.g ICandle - just so that I can write code without running Ninjatrader every 5 mins to test it.
Its not ideal. Could something be done please?
[Small test project attached which shows the problem]
Comment