-
Notifications
You must be signed in to change notification settings - Fork 8
Testing
Since there is a lot of transformer magic going on under the hood, there is a good reason to test that your HttpRequestMessages actually are sent as you expect them to.
Notice however, that by using these tools, it is not possible to test the effects of the HttpClient used to actually send the request. Like verifying that any default request headers added to the HttpClient are in the request. This is ok, since this behaviour is the behaviour of the HttpClient, not Web Anchor.
To begin testing your api, head over to the source and check out these files https://github.com/mattiasnordqvist/Web-Anchor/tree/master/WebAnchor.Tests/TestUtils. You should copy these files to your test project and use them as helping hands when writing your tests. After copying them you can of course change them as much as you like, to support your testing needs. The main entry point is the WebAnchorTest. This is how I use it.
These files are now included in WebAnchor since 6.1.0.
This class (WebAnchorTest) is a class that I let my own test-classes derive from. Then, I basically call the TestTheRequest-method with my Api-interface and derived ApiSettings. Watch this:
Say I have a created a transformer that always appends a constant query string parameter
public class AddExtraParameterTransformer : IParameterListTransformer
{
public IEnumerable<Parameter> Apply(IEnumerable<Parameter> parameters, RequestTransformContext requestTransformContext)
{
foreach (var p in parameters)
{
yield return p;
}
yield return Parameter.CreateQueryParameter("extra", new object[] { 3 });
}
public void ValidateApi(Type type)
{
}
}
And my settings look like this
public class AddExtraParameterSettings : DefaultApiSettings
{
public AddExtraParameterSettings()
{
Request.ParameterListTransformers.Add(new AddExtraParameterTransformer());
}
}
Provided that you do have an Api looking like this
[BaseLocation("api/customer")]
public interface ICustomerApi
{
[Get("")]
Task<HttpResponseMessage> GetCustomers(string filter = null);
}
you can test it like this, using NUnit.
[TestFixture]
public class MyTests : WebAnchorTest
{
[Test]
public void MyTest()
{
TestTheRequest<ICustomerApi>(api => api.GetCustomers("test"), m =>
{
Assert.AreEqual(HttpMethod.Get, m.Method);
Assert.AreEqual("api/customer?filter=test&extra=3", m.RequestUri.ToString());
}, settings: new AddExtraParameterSettings());
}
}
When you subclass WebAnchorTest, you also get a GetResponse
-method which can be used to simulate what happens after a HttpResponseMessage
arrives to Web Anchor.
[BaseLocation("api/customer")]
public interface ICustomerApi
{
[Get("{id}")]
Task<Customer> GetCustomer(int id);
}
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
}
Wanna see that your customer is deserialized correctly?
[TestFixture]
public class MyTests : WebAnchorTest
{
[Test]
public async Task MyTest()
{
var response = new HttpResponseMessage(HttpStatusCode.OK)
{
Content = new StringContent(@"{id: 9, name: ""Captain Falcon""}", Encoding.UTF8, "application/json")
};
}
}
var result = await GetResponse<ICustomerApi, Task<Customer>>(api => api.GetCustomer(9), response);
Assert.AreEqual("Captain Falcon", result.Name);
Assert.AreEqual(9, result.Id);
GetResponse will feed the given response object to the parts of the Web Anchor machinery that takes on all response messages. This means that method referenced in the api-lambda is actually never invoked, so parameters you pass in there (9 in this case) are irrelevant.
- Getting started
- Basics (Http GET & Base Location)
- Basics pt. 2 (POST/PUT/DELETE, HttpResponseMessage, Exceptions, HttpClient, IDisposable)
- Building an HttpRequestMessage
- Parameter attributes
- Handling responses
- ApiSettings
- Typical setup (Develop/Test/Production & Mocking)
- Logging
- Testing
- Generic Api
- Multipart