Docking private classes without public constructors?

The specific class I'm testing depends on the HttpSessionState object.

The HttpSessionState class does not have common constructors. The test class uses this object only as a NameValue repository. The class is used in the ASMX web service to return information for a specific method.

I'm going to create a facade around the HttpSessionState class, where I can provide a dictionary <string, string> instead of a Session object in testing.

Is this a good idea or standard practice?

+6
source share
3 answers

Yes, as the old saying goes, there is nothing that cannot be solved by adding another layer of abstraction. Usually I just hide the type of interface, where the interface methods are the only ones that are needed to perform the actions that I want in this type.

Just mock the interface that HttpSessionState hides and makes Asserts to use the interface, in Rhino Mocks it's just AssertWasCalled (d => ....), etc.

+8
source

You can subclass the class HttpSessionStateBase. This answer shows how to implement this for Moq, but you can still use the MockHttpSession class with Rhino Mocks (I assume I haven't used Rhino Mocks).

public class MockHttpSession : HttpSessionStateBase { Dictionary<string, object> sessionStorage = new Dictionary<string, object>(); public override object this[string name] { get { return sessionStorage[name]; } set { sessionStorage[name] = value; } } } 

A fairly detailed discussion of how to mock .NET classes can be found on Scott Hanselman's blog here .

+2
source

You can mock any type, even closed ones, using the Microsoft Moles Isolation framework for .NET . Does a bit of customization work, but may be better than adding another level of abstraction. HttpContext and HttpSessionState considered using moles here . There is another similar discussion here .

+2
source

Source: https://habr.com/ru/post/907739/


All Articles