my code does this
string domainUrl = HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Authority);
int result = string.Compare(domainUrl, "http://www.facebookmustdie.com");
// do something with the result...
How can I mock this so my unit test passes, do I have to mock the whole HttpContext class? And if that was the case how would I inject that into the code so the 'correct' HttpContext is used when the unit test is run
You don't need to mock it:
var sb = new StringBuilder();
TextWriter w = new StringWriter(sb);
var context = new HttpContext(new HttpRequest("", "http://www.example.com", ""), new HttpResponse(w));
HttpContext.Current = context;
Console.WriteLine(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Authority));
The HttpContext singleton can't be easily mocked, and don't play well with unit testing either, because it ties you with the IIS infrastructure.
It's true that Moles can do the job too, but the true issue is the heavy couplage with IIS.
You should rather pass the relevant request data (url for exemple in your case) to your function or class, in order to be able to isolate your logic from the infrastructure. This way, you will be able to separate it from IIS, and run it on a testing infrastructure easily.
Basically, there are two possibilities:
Use TypeMock Isolator or Moles to mock HttpContext.
Introduce an interface for the whole HttpContext class or just for a UrlHelper and pass an instance of a class that implements that interface into your class. Keyword: Dependency Injection (DI)
I don't know what type of project you're writing this code for, but if it's an MVC project I'd suggest re-writing your code to use HttpContextBase instead - if that's possible. Then you can create a stub or mock of this and inject that for your tests. Request.Url returns System.Uri so you'll have to create an instance of this and set that on your context stub/mock.
Example for above :
namespace Tests
{
[TestClass()]
public class MyTests
{
[ClassInitialize()]
public static void Init(TestContext context)
{
// mock up HTTP request
var sb = new StringBuilder();
TextWriter w = new StringWriter(sb);
var httpcontext = new HttpContext(new HttpRequest("", "http://www.example.com", ""), new HttpResponse(w));
HttpContext.Current = httpcontext;
}
[TestMethod()]
public void webSerivceTest()
{
// the httpcontext will be already set for your tests :)
}
}
}
Related
I have build a WebAPI and want to create a unit test project to have my services tested automatically.
The flow of my WebAPI is simple:
Controller (DI Service) -> Service (DI Repository) -> _repo CRUD
Suppose I have a service like:
public int Cancel(string id) //change status filed to 'n'
{
var item = _repo.Find(id);
item.status = "n";
_repo.Update(item);
return _repo.SaveChanges();
}
And I want to build a unit test, which just use InMemoryDatabase.
public void Cancel_StatusShouldBeN() //Testing Cancel() method of a service
{
_service.Insert(item);
int rs = _service.Cancel(item.Id);
Assert.Equal(1, rs);
item = _service.GetByid(item.Id);
Assert.Equal("n", item.status);
}
I've searched other related question, found that
You can't use dependency injections on test classes.
I just want to know if there is any other solution to achive my unit test idea?
When unit testing, you should just supply all the dependencies of the class you are testing explicitly. That is dependency injection; not having the service construct its dependencies on its own but making it rely on the outer component to provide them. When you are outside of a dependency injection container and inside a unit test where you are manually creating the class you are testing, it’s your responsibility to provide the dependencies.
In practice, this means that you either provide mocks or actual objects to the constructor. For example, you might want to provide a real logger but without a target, a real database context with a connected in-memory database, or some mocked service.
Let’s assume for this example, that the service you are testing looks like this:
public class ExampleService
{
public ExampleService(ILogger<ExampleService> logger,
MyDbContext databaseContext,
UtilityService utilityService)
{
// …
}
// …
}
So in order to test ExampleService, we need to provide those three objects. In this case, we will do the following for each:
ILogger<ExampleService> – we will use a real logger, without any attached target. So any call on the logger will work properly without us having to provide some mock, but we do not need to test the log output, so we do not need a real target
MyDbContext – Here, we’ll use the real database context with an attached in-memory database
UtilityService – For this, we will create a mock which just setups the utility method we need inside the methods we want to test.
So a unit test could look like this:
[Fact]
public async Task TestExampleMethod()
{
var logger = new LoggerFactory().CreateLogger<ExampleService>();
var dbOptionsBuilder = new DbContextOptionsBuilder().UseInMemoryDatabase();
// using Moq as the mocking library
var utilityServiceMock = new Mock<UtilityService>();
utilityServiceMock.Setup(u => u.GetRandomNumber()).Returns(4);
// arrange
using (var db = new MyDbContext(dbOptionsBuilder.Options))
{
// fix up some data
db.Set<Customer>().Add(new Customer()
{
Id = 2,
Name = "Foo bar"
});
await db.SaveChangesAsync();
}
using (var db = new MyDbContext(dbOptionsBuilder.Options))
{
// create the service
var service = new ExampleService(logger, db, utilityServiceMock.Object);
// act
var result = service.DoSomethingWithCustomer(2);
// assert
Assert.NotNull(result);
Assert.Equal(2, result.CustomerId);
Assert.Equal("Foo bar", result.CustomerName);
Assert.Equal(4, result.SomeRandomNumber);
}
}
In your specific Cancel case, you want to avoid using any methods of the service you are not currently testing. So if you want to test Cancel, the only method you should call from your service is Cancel. A test could look like this (just guessing the dependencies here):
[Fact]
public async Task Cancel_StatusShouldBeN()
{
var logger = new LoggerFactory().CreateLogger<ExampleService>();
var dbOptionsBuilder = new DbContextOptionsBuilder().UseInMemoryDatabase();
// arrange
using (var db = new MyDbContext(dbOptionsBuilder.Options))
{
// fix up some data
db.Set<SomeItem>().Add(new SomeItem()
{
Id = 5,
Status = "Not N"
});
await db.SaveChangesAsync();
}
using (var db = new MyDbContext(dbOptionsBuilder.Options))
{
// create the service
var service = new YourService(logger, db);
// act
var result = service.Cancel(5);
// assert
Assert.Equal(1, result);
}
using (var db = new MyDbContext(dbOptionsBuilder.Options))
{
var item = db.Set<SomeItem>().Find(5);
Assert.Equal(5, item.Id);
Assert.Equal("n", item.Status);
}
}
Btw. note that I’m opening up a new database context all the time in order to avoid getting results from the cached entities. By opening a new context, I can verify that the changes actually made it into the database completely.
I'm using NUnit and RhinoMocks for unit testing on the (WebApi) project.
There is a method I'm trying to write test for, which is supposed to add an item to HttpContext.Current.Items.
public override void OnActionExecuting(HttpActionContext actionContext)
{
HttpContext.Current.Items.Add("RequestGUID", Guid.NewGuid());
base.OnActionExecuting(actionContext);
}
I have no idea how can I make HttpContext.Current.Items available to the method when ran from within a test method. How can I achieve this?
Also, how can I check if the item has been added (what kind of assertion can/should I use)
You don't need to refactor your code\use RhinoMocks at all for testing it.
Your UT should be similar to the following example:
[Test]
public void New_GUID_should_be_added_when_OnActionExecuting_is_executing()
{
//arrange section:
const string REQUEST_GUID_FIELD_NAME = "RequestGUID";
var httpContext = new HttpContext(
new HttpRequest("", "http://google.com", ""),
new HttpResponse(new StringWriter())
);
HttpContext.Current = httpContext;
//act:
target.OnActionExecuting(new HttpActionContext());
//assert section:
Assert.IsTrue(HttpContext.Current.Items.Contains(REQUEST_GUID_FIELD_NAME));
var g = HttpContext.Current.Items[REQUEST_GUID_FIELD_NAME] as Guid?;
if (g == null)
{
Assert.Fail(REQUEST_GUID_FIELD_NAME +
" is not a GUID, it is :: {0}",
HttpContext.Current.Items[REQUEST_GUID_FIELD_NAME]);
}
Assert.AreNotEqual(Guid.Empty, g.Value);
}
BTW, you can split this test to 2:
verifies that the RequestGUID is being populated with a GUID
verifies that the GUID is not Guid.Empty
Consider the following test which confirms that when an object is added to the HttpContentConatiner class it's resulting MD5, which is stored on the content container matches the result of serializing and hashing the body content externally (which is how it would be used).
[Fact]
public void When_body_added_correctly_MD5_matches_an_external_hash_of_the_same_content()
{
var contentStub = new object();
var serializer = new NewtonSoftJsonSerializer();
var hasher = new Hmac256Hasher();
var contentContainer = new HttpContentContainer(serializer, hasher);
contentContainer.AddBody(contentStub);
Assert.Equal(hasher.Hash(serializer.Serialize(contentStub), "Key"),
contentContainer.ContentMD5.Value);
}
In this test I use an actual implementation for both the serializer and the hasher as opposed to mocking out these two objects. This now means that the test depends on both the hasher and the serializer working correctly as their implementations have now been pulled into the test scope which I worry may make my tests brittle.
My Question
Given the above example, should I mock the serializer and hasher for maintainability purposes or is it ok to depend on external services like this?
New Code based on Answer:
[Fact]
public void When_a_valid_body_is_added_ContentMD5_Value_is_populated()
{
var serializerMock = new Mock<ISerializer>();
serializerMock.Setup(serializer => serializer.Serialize(It.IsAny<object>()))
.Returns("serializedContent");
var hasherMock = new Mock<IHasher>();
hasherMock.Setup(hasher => hasher.Hash(It.IsAny<string>(), It.IsAny<string()))
.Returns("MD5");
var contentContainer =
new HttpContentContainer(serializerMock.Object, hasherMock.Object);
contentContainer.AddBody(new object());
Assert.NotEmpty(contentContainer.ContentMD5.Value);
}
I would prefer to Mock both Hasher as well as the Serializer.
Reason - Both Hash and Serialize method of these dependencies could be assumed to perform expected functions, and this can be the expectation of the Mock. A test failure would then indicate the failure of Object under test with certainty.
The short takeaway now that the solution has been found:
AutoFixture returns frozen the mock just fine; my sut that was also generated by AutoFixture just had a public property with a local default that was important for the test and that AutoFixture set to a new value. There is much to learn beyond that from Mark's answer.
Original question:
I started trying out AutoFixture yesterday for my xUnit.net tests that have Moq all over them. I was hoping to replace some of the Moq stuff or make it easier to read, and I'm especially interested in using AutoFixture in the SUT Factory capacity.
I armed myself with a few of Mark Seemann's blog posts on AutoMocking and tried to work from there, but I didn't get very far.
This is what my test looked like without AutoFixture:
[Fact]
public void GetXml_ReturnsCorrectXElement()
{
// Arrange
string xmlString = #"
<mappings>
<mapping source='gcnm_loan_amount_min' target='gcnm_loan_amount_min_usd' />
<mapping source='gcnm_loan_amount_max' target='gcnm_loan_amount_max_usd' />
</mappings>";
string settingKey = "gcCreditApplicationUsdFieldMappings";
Mock<ISettings> settingsMock = new Mock<ISettings>();
settingsMock.Setup(s => s.Get(settingKey)).Returns(xmlString);
ISettings settings = settingsMock.Object;
ITracingService tracing = new Mock<ITracingService>().Object;
XElement expectedXml = XElement.Parse(xmlString);
IMappingXml sut = new SettingMappingXml(settings, tracing);
// Act
XElement actualXml = sut.GetXml();
// Assert
Assert.True(XNode.DeepEquals(expectedXml, actualXml));
}
The story here is simple enough - make sure that SettingMappingXml queries the ISettings dependency with the correct key (which is hard coded/property injected) and returns the result as an XElement. The ITracingService is relevant only if there's an error.
What I was trying to do is get rid of the need to explicitly create the ITracingService object and then manually inject the dependencies (not because this test is too complex, but because it is simple enough to try things out and understand them).
Enter AutoFixture - first attempt:
[Fact]
public void GetXml_ReturnsCorrectXElement()
{
// Arrange
IFixture fixture = new Fixture();
fixture.Customize(new AutoMoqCustomization());
string xmlString = #"
<mappings>
<mapping source='gcnm_loan_amount_min' target='gcnm_loan_amount_min_usd' />
<mapping source='gcnm_loan_amount_max' target='gcnm_loan_amount_max_usd' />
</mappings>";
string settingKey = "gcCreditApplicationUsdFieldMappings";
Mock<ISettings> settingsMock = new Mock<ISettings>();
settingsMock.Setup(s => s.Get(settingKey)).Returns(xmlString);
ISettings settings = settingsMock.Object;
fixture.Inject(settings);
XElement expectedXml = XElement.Parse(xmlString);
IMappingXml sut = fixture.CreateAnonymous<SettingMappingXml>();
// Act
XElement actualXml = sut.GetXml();
// Assert
Assert.True(XNode.DeepEquals(expectedXml, actualXml));
}
I would expect CreateAnonymous<SettingMappingXml>(), upon detection of the ISettings constructor parameter, to notice that a concrete instance has been registered for that interface and inject that - however, it doesn't do that but instead creates a new anonymous implementation.
This is especially confusing as fixture.CreateAnonymous<ISettings>() does indeed return my instance -
IMappingXml sut = new SettingMappingXml(fixture.CreateAnonymous<ISettings>(), fixture.CreateAnonymous<ITracingService>());
makes the test perfectly green, and this line is exactly what I had expected AutoFixture to do internally when instantiating SettingMappingXml.
Then there's the concept of freezing a component, so I went ahead just freezing the mock in the fixture instead of getting the mocked object:
fixture.Freeze<Mock<ISettings>>(f => f.Do(m => m.Setup(s => s.Get(settingKey)).Returns(xmlString)));
Sure enough this works perfectly fine - as long as I call the SettingMappingXml constructor explicitly and don't rely on CreateAnonymous().
Simply put, I don't understand why it works the way it apparently does, as it goes against any logic I can conjure up.
Normally I would suspect a bug in the library, but this is something so basic that I'm sure others would have run into this and it would long have been found and fixed. What's more, knowing Mark's assiduous approach to testing and DI, this can't be unintentional.
That in turn means I must be missing something rather elementary. How can I have my SUT created by AutoFixture with a preconfigured mocked object as a dependency? The only thing I'm sure about right now is that I need the AutoMoqCustomization so I don't have to configure anything for the ITracingService.
AutoFixture/AutoMoq packages are 2.14.1, Moq is 3.1.416.3, all from NuGet. .NET version is 4.5 (installed with VS2012), behavior is the same in VS2012 and 2010.
While writing this post, I discovered that some people were having problems with Moq 4.0 and assembly binding redirects, so I meticulously purged my solution of any instances of Moq 4 and had Moq 3.1 installed by installing AutoFixture.AutoMoq into "clean" projects. However, the behavior of my test remains unchanged.
Thank you for any pointers and explanations.
Update: Here's the constructor code Mark asked for:
public SettingMappingXml(ISettings settingSource, ITracingService tracing)
{
this._settingSource = settingSource;
this._tracing = tracing;
this.SettingKey = "gcCreditApplicationUsdFieldMappings";
}
And for completeness, the GetXml() method looks like this:
public XElement GetXml()
{
int errorCode = 10600;
try
{
string mappingSetting = this._settingSource.Get(this.SettingKey);
errorCode++;
XElement mappingXml = XElement.Parse(mappingSetting);
errorCode++;
return mappingXml;
}
catch (Exception e)
{
this._tracing.Trace(errorCode, e.Message);
throw;
}
}
SettingKey is just an automatic property.
Assuming that the SettingKey property is defined as follows, I can now reproduce the issue:
public string SettingKey { get; set; }
What happens is that the Test Doubles injected into the SettingMappingXml instance are perfectly fine, but because the SettingKey is writable, AutoFixture's Auto-properties feature kicks in and modifies the value.
Consider this code:
var fixture = new Fixture().Customize(new AutoMoqCustomization());
var sut = fixture.CreateAnonymous<SettingMappingXml>();
Console.WriteLine(sut.SettingKey);
This prints something like this:
SettingKey83b75965-2886-4308-bcc4-eb0f8e63de09
Even though all the Test Doubles are properly injected, the expectation in the Setup method isn't met.
There are many ways to address this issue.
Protect invariants
The proper way to resolve this issue is to use the unit test and AutoFixture as a feedback mechanism. This is one of the key points in GOOS: problems with unit tests are often a symptom about a design flaw rather than the fault of the unit test (or AutoFixture) itself.
In this case it indicates to me that the design isn't fool-proof enough. Is it really appropriate that a client can manipulate the SettingKey at will?
As a bare minimum, I would recommend an alternative implementation like this:
public string SettingKey { get; private set; }
With that change, my repro passes.
Omit SettingKey
If you can't (or won't) change your design, you can instruct AutoFixture to skip setting the SettingKey property:
IMappingXml sut = fixture
.Build<SettingMappingXml>()
.Without(s => s.SettingKey)
.CreateAnonymous();
Personally, I find it counterproductive to have to write a Build expression every time I need an instance of a particular class. You can decouple how the SettingMappingXml instance are created from the actual instantiation:
fixture.Customize<SettingMappingXml>(
c => c.Without(s => s.SettingKey));
IMappingXml sut = fixture.CreateAnonymous<SettingMappingXml>();
To take this further, you can encapsulate that Customize method call in a Customization.
public class SettingMappingXmlCustomization : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Customize<SettingMappingXml>(
c => c.Without(s => s.SettingKey));
}
}
This requires you to create your Fixture instance with that Customization:
IFixture fixture = new Fixture()
.Customize(new SettingMappingXmlCustomization())
.Customize(new AutoMoqCustomization());
Once you get more than two or three Customizations to chain, you may get tired of writing that method chain all the time. It's time to encapsulate those Customizations into a set of conventions for your particular library:
public class TestConventions : CompositeCustomization
{
public TestConventions()
: base(
new SettingMappingXmlCustomization(),
new AutoMoqCustomization())
{
}
}
This enables you to always create the Fixture instance like this:
IFixture fixture = new Fixture().Customize(new TestConventions());
The TestConventions gives you a central place where you can go and occasionally modify your conventions for the test suite when you need to do so. It reduces the maintainability tax of your unit tests and helps keep the design of your production code more consistent.
Finally, since it looks as though you are using xUnit.net, you could utilize AutoFixture's xUnit.net integration, but before you do that you'd need to use a less imperative style of manipulating the Fixture. It turns out that the code which creates, configures and injects the ISettings Test Double is so idiomatic that it has a shortcut called Freeze:
fixture.Freeze<Mock<ISettings>>()
.Setup(s => s.Get(settingKey)).Returns(xmlString);
With that in place, the next step is to define a custom AutoDataAttribute:
public class AutoConventionDataAttribute : AutoDataAttribute
{
public AutoConventionDataAttribute()
: base(new Fixture().Customize(new TestConventions()))
{
}
}
You can now reduce the test to the bare essentials, getting rid of all the noise, enabling the test to succinctly express only what matters:
[Theory, AutoConventionData]
public void ReducedTheory(
[Frozen]Mock<ISettings> settingsStub,
SettingMappingXml sut)
{
string xmlString = #"
<mappings>
<mapping source='gcnm_loan_amount_min' target='gcnm_loan_amount_min_usd' />
<mapping source='gcnm_loan_amount_max' target='gcnm_loan_amount_max_usd' />
</mappings>";
string settingKey = "gcCreditApplicationUsdFieldMappings";
settingsStub.Setup(s => s.Get(settingKey)).Returns(xmlString);
XElement actualXml = sut.GetXml();
XElement expectedXml = XElement.Parse(xmlString);
Assert.True(XNode.DeepEquals(expectedXml, actualXml));
}
Other options
To make the original test pass, you could also just switch off Auto-properties entirely:
fixture.OmitAutoProperties = true;
In the first test you can create an instance of the Fixture class with the AutoMoqCustomization applied:
var fixture = new Fixture()
.Customize(new AutoMoqCustomization());
Then, the only changes are:
Step 1
// The following line:
Mock<ISettings> settingsMock = new Mock<ISettings>();
// Becomes:
Mock<ISettings> settingsMock = fixture.Freeze<Mock<ISettings>>();
Step 2
// The following line:
ITracingService tracing = new Mock<ITracingService>().Object;
// Becomes:
ITracingService tracing = fixture.Freeze<Mock<ITracingService>>().Object;
Step 3
// The following line:
IMappingXml sut = new SettingMappingXml(settings, tracing);
// Becomes:
IMappingXml sut = fixture.CreateAnonymous<SettingMappingXml>();
That's it!
Here is how it works:
Internally, Freeze creates an instance of the requested type (e.g. Mock<ITracingService>) and then injects it so it will always return that instance when you request it again.
This is what we do in Step 1 and Step 2.
In Step 3 we request an instance of the SettingMappingXml type which depends on ISettings and ITracingService. Since we use Auto Mocking, the Fixture class will supply mocks for these interfaces. However, we have previously injected them with Freeze so the already created mocks are now automatically supplied.
I got a mvc 3 project where I want to mock HttpResonseBase and HttpRequestBase. Im using RhinoMocks 3.6 to mock myobjects. My test code rightnow looks like this.
[TestMethod]
public void Test()
{
MockRepository repo = new MockRepositoy();
HttpContextBase mockHttpContext= repo.StrictMock<HttpContextBase>();
HttpRequestBase mockRequest = repo.StrictMock<HttpRequestBase>();
HttpResponseBase mockResponse = repo.StrictMock<HttpResponseBase>();
ICookie mockCookie = repo.StrictMock<ICookie>();
Controller instanceToTest = new Controller(mockCookie);
SetupResult.For(mockHttpContext.Request).Return(mockRequest);
SetupResult.For(mockHttpContext.Response).Return(mockResponse);
mocks.Replay(context);
instanceToTest.ControllerContext = new ControllerContext(mockHttpContext, new RouteData(), instanceToTest);
mockCookie.Expect(x=>x.MethodToExpect("Test",mockRequest,mockResponse);
mockRepository.ReplayAll();
instanceToTest.MethodToTest();
mockRepository.VerifyAll();
}
When im running the test I get this errormessage;
Rhino.Mocks.Exceptions.ExpectationViolationException: ICookie.MethodToExpect("Test", System.Web.HttpResponseBase, System.Web.HttpRequestBase); Expected #0, Actual #1.
ICookie.MethodToExpect("Test", HttpResponseBaseProxy); Expected #1, Actual #0.
What am I doing wrong?
The problem here is that you use StrictMock - it means that if you call a method on the Mock object that you haven't set any expectations on it, VerifyAllExpectations will fail. You could use MockRepository.GenerateMock<T> method instead of the StrictMock.
Another comment is that you'd better stick with the RhinoMocks AAA syntax (using the Expect, Stub and VerifyAllExpectations methods instead of ReplayAll, SetupResult etc...)
Here's how your code may look like with pure AAA syntax:
[TestMethod]
public void Test()
{
// Arrange(A) - create your objects, mocks and stubs
// The context is a Stub - you just want it to return the mocked request and response
HttpContextBase mockHttpContext= MockRepository.GenerateStub<HttpContextBase>();
HttpRequestBase mockRequest = MockRepository.GenerateMock<HttpRequestBase>();
HttpResponseBase mockResponse = MockRepository.GenerateMock<HttpResponseBase>();
ICookie mockCookie = MockRepository.GenerateMock<ICookie>();
Controller instanceToTest = new Controller(mockCookie);
// Stub will return the mocked request and response on every call (similar to SetupResult)
mockHttpContext.Stub(x => x.Request).Return(mockRequest);
mockHttpContext.Stub(x => x.Response).Return(mockResponse);
instanceToTest.ControllerContext = new ControllerContext(mockHttpContext, new RouteData(), instanceToTest);
mockCookie.Expect(x=>x.MethodToExpect("Test",mockRequest,mockResponse);
// Act(A) - do the actual operations on the tested class
instanceToTest.MethodToTest();
// Assert (A) - Verify your expectations
mockCookie.VerifyAllExpectations();
}