I am trying to mock out HttpContext so that I can unit test my controller's Request.IsAuthenicated call. I am using the code that I found at Scott Hanselman's blog to simulate HttpContext using rhino.mocks.
so i have this unit test piece:
PostsController postsController = new PostsController(postDL);
mocks.SetFakeControllerContext(postsController);
Expect.Call(postsController.Request.IsAuthenticated).Return(true);
In my controller action, I have something like
if(Request.IsAuthenticated)....
when I try to run the unit test, the test fails throwing a null exception, and when I try to debug the unit test, I see that the HttpContext is never assigned to the controller.
any ideas?
This should work:
PostsController postsController = new PostsController(postDL);
var context = mocks.Stub<HttpContextBase>();
var request = mocks.Stub<HttpRequestBase>();
SetupResult.For(request.IsAuthenticated).Return(true);
SetupResult.For(context.Request).Return(request);
postsController.ControllerContext = new ControllerContext(context, new RouteData(), postsController);
This may be of some use to you, worked for me in a similar scenario:
http://haacked.com/archive/2007/06/19/unit-tests-web-code-without-a-web-server-using-httpsimulator.aspx
You may find the post I wrote on this to be helpful in some way
http://santoshbenjamin.wordpress.com/2008/08/04/mock-httpcontext-and-session-state/
cheers
benjy
Now, for disclosure, I have yet to get my hands dirty with most of the stuff you are working with, however:
If you want to mock the IsAuthenticated, why not just create a static class to return a bool that can the be manipulated by your test code?
This is a bit rough round the edges, but hopefully you get the idea:
interface IAuthenticationChecker
{
bool IsAuthenticated { get; }
}
public class MockAuthenticationChecker : IAuthenticationChecker
{
static bool _authenticated = false;
public static void SetAuthenticated(bool value)
{
_authenticated = value;
}
#region IAuthenticationChecker Members
public bool IsAuthenticated
{
get { return _authenticated; }
}
#endregion
}
public class RequestAuthenticationChecker : IAuthenticationChecker
{
#region IAuthenticationChecker Members
public bool IsAuthenticated
{
get {
if (HttpContext.Current == null)
throw new ApplicationException(
"Unable to Retrieve IsAuthenticated for Request becuse there is no current HttpContext.");
return HttpContext.Current.Request.IsAuthenticated;
}
}
#endregion
}
You can then use a reference to either at app level, yeah it means you have to add a reference at app level, and you need to use a different ref rather than Request, but you also get complete control over the authentication for testing :)
FYI - this is totally open to being blown apart, I threw it together in about a minute :)
Here is one simple way to fake the context, found it from Jeff's blog :
TextWriter tw = new StringWriter();
HttpWorkerRequest wr = new SimpleWorkerRequest("/webapp", "c:\\inetpub\\wwwroot\\webapp\\", "default.aspx", "", tw);
HttpContext.Current = new HttpContext(wr);
Here's a class that may be useful. It handles ajax requests, user authentication, request parameters and more: https://gist.github.com/3004119
Related
I am asking this because after long time searching I haven't found a good answer on this yet...
Here is what I want:
Example: I have a domain model "JobPosting" which a user should be able to change state to published, if it is still a draft. Before publishing I must not only validate the model properties I must also validate many different requirements regarding the user account, it's registered company etc. All this validation logic is put into a service layer. So far so good...
This is how my service layer looks like:
public IValidationResult ValidatePublish(JobPosting jobPosting){
...
}
public void Publish(JobPosting jobPosting){
jobPosting.State = JobPostingState.Published;
...
}
Any my controller:
public ActionResult Publish(PublishViewModel model){
...
var validationResult = _jobService.ValidatePublish(jobPosting);
if(validationResult.Success){
_jobService.Publish(jobPosting);
...
}
...
}
And here now my questions:
I want to be able to call the ValidatePublish from the controller to show validation errors in the view. However I must never be able to publish a job when validation fails.
So to have my code more robust I added a second validation check in my Publish method in service layer:
public void Publish(JobPosting jobPosting){
if(ValidatePublish(jobPosting).Success){
jobPosting.State = JobPostingState.Published;
...
}
}
but I have not such a good feeling with this approach because now I am calling the validation twice when validation is OK during each controller publish request.
What do you think. Is the second call to much? Is there a better approach?
I am asking because my whole application looks like that and if I would ever forget a validation call in controller I might end up with an not allowed domain model state in database. That's why I added the second validation check in each service method.
Thanks in advance for your thoughts on this!!!
One quick solution might be to have the Publisher class require the JobPosting and IValidationResult objects as arguments.
public void Publish(JobPosting jobPosting, IValidationResult validation)
{
if (validation.IsValid)
{
jobPosting.State = JobPostingState.Published;
// other work here...
}
}
Your Controller can then call the Validator, receive an IValidationResult and pass that back to the presentation layer if needed. Otherwise pass on to Publisher
public ActionResult Publish(PublishViewModel model)
{
var validationResult = _jobService.ValidatePublish(jobPosting);
if(validationResult.Success) _jobService.Publish(jobPosting, validationResult);
else return View("error", validationResult);
}
Edit:
A cleaner solution may be to have the Publisher class return a PublishAttempt result.
public class PublishAttempt : IValidationResult
{
public enum AttemptOutcome {get; set;}
}
public ActionResult Publish(PublishViewModel model)
{
var attempt = _jobService.Publish(jobPosting);
if (attempt.Success) return View("success");
else return View("error", attempt.ValidationResults);
}
The following just came into my mind... what do you think:
I change my service method to:
public IValidationResult Publish(JobPosting jobPosting, bool validateOnly = false){
var validationResult = ValidatePublish(jobPosting);
if(validateOnly) return validationResult;
jobPosting.State = JobPostingState.Published;
...
return validationResult;
}
And then in controller I always call only the Publish method and not the extra ValidatePublish anymore:
public ActionResult Publish(PublishViewModel model)
{
var validationResult = _jobService.Publish(jobPosting);
if(!validationResult.Success) return View("error", validationResult);
}
And when I need only simple validation I do
var validationResult = _jobService.Publish(jobPosting, true);
Is this okey to do it like that?
Or is it not good looking if a normal service call returns IValidationResult?
I have a method on an ApiController that looks like this:
public IEnumerable<Items> GetSlideSets() {
IServiceClass serviceClass = new ServiceClass();
//...
Yes, I am aware that this is not good design but I'm addressing this issue in a different iteration.
At a certain point in my application I need to call this functionality from within the project itself so I thought I could simply reuse the controller (and why not, I can pluck it out of my IoC container). The only problem is that in this case, I need to inject my own implementation of IServiceClass, easy enough:
public IEnumerable<Items> GetSlideSets(IServiceClass serviceClass = null) {
serviceClass = serviceClass ?? new ServiceClass();
//...
Except now I am getting errors when calling this via a regular Api call Optionalparameter 'serviceClass' is not supported by FormatterParameterBinding.
I know that there are various attributes that control bindings. Is there one that I can put on the parameter to say it shouldn't bind.
Like others have mentioned, it's probably a better idea to inject the dependency in the constructor.
But if you really must avoid binding an action parameter, there isn't a built-in attribute but you can create one pretty easily. Here's what it could look like:
public class DontBindAttribute : ParameterBindingAttribute
{
public override HttpParameterBinding GetBinding(HttpParameterDescriptor parameter)
{
return new DontBindParameterBinding(parameter);
}
private class DontBindParameterBinding : HttpParameterBinding
{
public DontBindParameterBinding(HttpParameterDescriptor parameter) : base(parameter)
{
}
public override Task ExecuteBindingAsync(ModelMetadataProvider metadataProvider, HttpActionContext actionContext, CancellationToken cancellationToken)
{
actionContext.ActionArguments.Add(Descriptor.ParameterName, Descriptor.DefaultValue);
var completedTaskSource = new TaskCompletionSource<object>();
completedTaskSource.SetResult(null);
return completedTaskSource.Task;
}
}
}
You just need to apply the attribute to the parameter afterwards:
public IEnumerable<Items> GetSlideSets([DontBind] IServiceClass serviceClass = null)
I searched a lot and still couldn't find a solid solution for this. Suppose you have methods in your application. This methods use "System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration" to access some setting in the web.config. If you try to test these methods, your tests will fail because your test project doesn't have web.config.
What is the best way to solve this problem. For projects with simple config file, I usually use a method like this as facade method.
public class Config
{
public static String getKeyValue(String keyName)
{
if (keyName == String.Empty) return String.Empty;
String result = "";
System.Configuration.Configuration rootWebConfig1 =
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(null);
if (rootWebConfig1.AppSettings.Settings.Count > 0)
{
System.Configuration.KeyValueConfigurationElement reportEngineKey =
rootWebConfig1.AppSettings.Settings[keyName];
if (reportEngineKey != null)
{
result = reportEngineKey.Value;
}
}
return result;
}
}
Every time I tried to set the path for OpenWebConfiguration( ), I got the error "The relative virtual path is not allowed"
To make that scenario more testable, I usually take the approach of making a "settings manager" of my own, and giving it an interface. So for example:
public interface IConfig
{
string GetSettingValue(string settingName);
}
Then I can have my "real" implementation:
public sealed class Config : IConfig
{
public string GetSettingValue(string settingName)
{
// your code from your getKeyValue() method would go here
}
}
Then my code that uses it would take in an instance of this (this is an example of the Dependency Inversion Principal):
public void DoStuff(IConfig configuration)
{
string someSetting = configuration.GetSettingValue("ThatThingINeed");
// use setting...
}
So now for my production code, I can call DoStuff and pass in an instance of Config.
When I need to test, I can use a mocking tool (Moq, JustMock, RhinoMocks, etc) to create a fake IConfig that returns a known value without hitting the actual .config file, or you can do it without a mocking framework by making your own mocks (and store them in your test project).
public class ConfigMock : IConfig
{
private Dictionary<string, string> settings;
public void SetSettingValue(string settingName, string value)
{
settings[settingName] = value;
}
public string GetSettingValue(string settingName)
{
return settings[settingName];
}
}
and
[Test]
public void SomeExampleTest()
{
var config = new ConfigMock();
config.SetSettingValue("MySetting", "SomeValue");
var underTest = new MyClass();
underTest.DoStuff(config);
}
The easiest way to do this is to use a mocking library such as moq. It takes a bit of time to figure it out, but once you do you can abstract away most of your plumbing to return the values you need for repeatable, consistent testing.
My current project based in Asp .net makes considerable use of Http handlers to process various requests? So, is there any way by which I can test the functionality of each of the handlers using unit test cases? We are using Nunit and Moq framework to facilitate unit testing.
I think these blog entries from a while back are relevant:
http://www.kongsli.net/nblog/2009/05/03/aspnet-35-improving-testability-with-systemwebabstractions/
http://www.kongsli.net/nblog/2009/05/28/testability-with-systemwebabstractions-and-no-mock-framework/
See example #2 in the first post for an example on how to unit test an HttpHandler.
If you dont care about unit tests and want something quick and dirty you can use Fiddler
if you want a more integrated approach (Unit testing) you can use the WebRequest and WebResponse.
You sure can, although I haven't done myself "in anger".
Use a System.Net.WebClient to make HTTP calls against your handlers, and evaluate what comes back, that will allow you to test the public facing interface of the handler.
In this example I've hard-coded my target, and I'm using a method on the WebClient that will return a string.
The WebClient also gives you access to the ResponseHeaders, Encoding and other useful 'webby' stuff; you can also upload info as well.
using System.Net;
namespace UnitTestHttpHandler
{
public class TestHarness
{
public static string GetString()
{
WebClient myWebClient = new WebClient();
return myWebClient.DownloadString("http://localhost/Morphfolia.Web/ContentList.ashx");
}
}
}
You can then use the TestHarness to call the target HttpHandler and verify the results in your tests (or use a better approach to your testing if you know one - I'm not a unit testing guru).
[TestMethod]
public void TestMethod1()
{
string x = UnitTestHttpHandler.TestHarness.GetString();
Assert.IsTrue(x.Length > 5);
}
The default interface for IHttpHandler is not testable because the param for ProcessRequest(HttpContext context) is not mockable.
This answer is inspired by this post.
To make your IHttpHandler implementation testable you must first make a small change so we can use the mockable HttpContextBase:
From:
class YourHttpHandler : IHttpHandler
{
public bool IsReusable => true;
public void ProcessRequest(HttpContext context)
{
/* Your handler implementation */
}
}
To:
class YourHttpHandler : IHttpHandler
{
public bool IsReusable => true;
public void ProcessRequest(HttpContext context)
=> ProcessRequest(new HttpContextWrapper(context));
public virtual void ProcessRequest(HttpContextBase context)
{
/* Your handler implementation */
}
}
Your functionality needs to be moved from ProcessRequest(HttpContext context) to ProcessRequest(HttpContextBase context).
The ProcessRequest(HttpContextBase context) method can now be called in your tests with a mock object to verify the functionality within.
It's useful the create a helper class that can be used to quickly instantiate YourHttpHandler, send a mocked request, and get access to the response.
public class YourHttpHandlerTester : YourHttpHandler
{
public class Response
{
public HttpResponseBase HttpResponse { get; }
public string Body { get; }
public Response(HttpResponseBase httpResponse, string body)
{
HttpResponseBase = httpResponse;
Body = body;
}
}
public Response ProcessRequest(HttpRequestBase httpRequest)
{
var memoryStream = new MemoryStream();
var httpResponse = CreateHttpResponse(memoryStream);
var httpContext = CreateHttpContext(httpRequest, httpResponse);
base.ProcessRequest(httpContext);
var response = CreateResponse(httpResponse, memoryStream);
return response;
}
protected virtual HttpResponseBase CreateHttpResponse(MemoryStream memoryStream)
{
var httpResponseBaseMock = new Moq.Mock<HttpResponseBase>();
httpResponseBaseMock.Setup(x => x.OutputStream).Returns(memoryStream);
return httpResponseBaseMock.Object;
}
protected virtual HttpContextBase CreateHttpContext(HttpRequestBase httpRequest, HttpResponseBase httpResponse)
{
var httpContextBaseMock = new Moq.Mock<HttpContextBase>();
httpContextBaseMock.Setup(x => x.Request).Returns(httpRequest);
httpContextBaseMock.Setup(x => x.Response).Returns(httpResponse);
return httpContextBaseMock.Object;
}
protected virtual Response CreateResponse(HttpResponseBase httpResponse, MemoryStream memoryStream)
{
memoryStream.Position = 0;
var body = new StreamReader(memoryStream).ReadToEnd();
var response = new Response(httpResponse, body);
return response;
}
}
This class can be used to quickly create readable tests:
[Fact]
public void Test()
{
var httpHandler = new YourHttpHandlerTester();
var request = CreateHttpRequestFromString("test");
var response = testHandler.ProcessRequest(request);
Assert.NotEmpty(response.Body);
}
public HttpRequestBase CreateHttpRequestFromString(string body)
{
var httpRequestBaseMock = new Moq.Mock<HttpRequestBase>();
var stream = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(body)))
httpRequestBaseMock.Setup(x => x.InputStream).Returns(stream);
return httpRequestBaseMock.Object;
}
YourHttpHandlerTester has plenty of virtual methods that can be overridden as necessary.
Likewise, the Response class can be improved so that it exposes methods from HttpResponseBase like the http status code, headers, and anything else you may want to check.
You can do INTEGRATION testing of the handler using the methods mentioned in the other answers, to do UNIT testing you will need to create some interfaces and extract the core functionality out of the handler, as well as create some mock objects.
You won't be able to unit test ALL parts of it because it relies upon outside resources (those you'll be mocking) - but that's fine, thats why we HAVE integration testing.
If you want to test the communication between your handlers and the Web UI then yes, integration testing is the way to go for that. In order to unit test your logic, could you not instead separate your business logic into other classes (I'd use a separate assembly for the business layer) and mock / unit test these classes instead outside of your presentation layer?
Once you have a structured (and unit tested) business layer that has been separated from the presentation layer your handlers can simply instantiate your concretes and invoke the provided methods. Once this is done, you can then move onto integration testing as your business logic will have been unit tested.
I'm trying to start using Unit Testing and I want to test the following Controller:
public class AjaxController : Controller
{
...
public JsonResult RateVideo( int userRating, long videoId )
{
string userName = User.Identity.Name;
...
}
}
I have a created a TestClass with the following method:
[ TestMethod
public void TestRateVideo()
{
//Arrange
AjaxController c = new AjaxController();
//Act
JsonResult jr = c.RateVideo(1, 1);
//Assert
//Not implemented yet
}
I select debug and run the test. When the code reaches the 1st statement:
string username = User.Identity.Name;
Debugging stops and I am presented with a message that says that the test failed.
Any guidance you can offer would be appreciated.
The most common problem testing Controllers is using functions that rely on the HttpContext.
The implementation of the User property is something like:
public IPrincipal get_User()
{
if (this.HttpContext != null)
{
return this.HttpContext.User;
}
return null;
}
As you can see, User will return null because the HtppContext has not being initialized and calling .Identity will throw an exception.
Fortunately MVC lets you set the ControllerContext property so you can create your own instance with a mocked HttpContext.
The MVCContrib project has some test helpers. You can use the TestControllerBuilder in MVCContrib.TestHelper.dll to build your controllers inside your test classes with mocked context.