This project is read-only.



Every proxied class inherits IProxy to facilitate configurating the proxy methods. In test code, the user will not have a need to have direct contact with this interface. I would be interested to know if you find need to use this interface to consider if I have implemented a poor design. Note that all the properties on IProxy are subject to change without notification as it is currently only supported for internal use, and not test use.



Some internal circumstances have need of accessing the parent Builder at runtime. One such case is determining the correct key name of templated functions. In such scenarios, the IProxy object uses the parent builder to build a key name for a given templated function. Again, this is an internal use case, the user will should not ever need to use this property.


When true, method configurations are used as expected. When false, all configurable methods called will fallback to the real method. As with all IProxy properties, this is for internal use. It makes it possible to invoke a constructor of a proxy before it is possible to configure proxied methods in the case that the constructor invokes virtual methods.


When true, a code trap for a proxy's property is activated when said property is invoked. Because a property's reflection information in C# cannot be accessed without a string, and because ProxyManager methods try to reduce the use of strings, this said code trap facilitates accessing property configurations. When ProxyManager#GetProp is called, this property is set to true. The property is then invoked which fires the code trap thereby not invoking any actual action in the property neither real nor fake. After the exception is caught and the property configuration is obtained, this property is set to false to allow expecting further property behavior. Again, leave to internal use.


A dictionary of the method configurations. Used internally to retrieve configurations as requested by the user or when invoking the proxy methods.


Used when constructing new method configurations during construction and template specializations. Used for internal use currently, I'd be curious what type of test needs to set this.


Used internally during construction to create all the method configurations. Calling this afterwards will effectively reset all the method configurations. However, there may also be other undefined behavior as this is not supported for external use.


Used internally during invocations to facilitate find a configuration for a method in runtime.

Last edited May 6, 2010 at 6:30 PM by payonel, version 6


No comments yet.