Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
The particular class I’m testing depends upon the HttpSessionState object.
The HttpSessionState class has no public constructors. The class under test is only using this object as a NameValue store. The class is used in an ASMX web service to return information for a particular method.
I’m thinking about creating a facade around the HttpSessionState class where I can provide a Dictionary <string, string> instead of the Session object in testing.
Is this a good idea or standard practice?
Yep, as the old saying goes, there’s nothing that can’t be solved by adding another layer of abstraction. I usually just hide the type behind an interface where the interface’s methods are the only ones needed to perform the actions I want on that type.
Just mock the interface that hides HttpSessionState, and do Asserts on the uses of the interface, in Rhino Mocks it’s just AssertWasCalled(d => ….) etc.