RESTful Day Eight: Unit Testing And Integration Testing in WebAPI Using NUnit And Moq framework: Part Two

Table of Contents

• Introduction
• Roadmap
• Setup Solution
• Testing WebAPI

  Step 1: Test Project
  Step 2: Install NUnit package
  Step 3: Install Moq framework
  Step 4: Install Entity Framework
  Step 5: Newtonsoft.Json
  Step 6: References
  

• ProductController Tests
  
  
  • Tests Setup
  • Declare variables
  • Write Test Fixture Setup
  • Write Test Fixture Tear Down
  • Write Test Tear down
  • Mocking Repository
  • GetAllProductsTest ()
  • GetProductByIdTest ()
  • Testing Exceptions from WebAPI
  • GetProductByWrongIdTest ()
  • GetProductByInvalidIdTest ()
  • CreateProductTest ()
  • UpdateProductTest ()
  • DeleteProductTest ()
  • DeleteInvalidProductTest ()
  • DeleteProductWithWrongIdTest ()
    
  • Integration Tests
  • Difference between Unit tests and Integration tests
  • Conclusion

Introduction

In my last article I explained how to write unit tests for business service layer. In this article we’ll learn  how to write unit tests for WebAPI controllers i.e. REST’s actual endpoints. I’ll use NUnit and Moq framework to write test cases for controller methods. I have already explained about installing NUnit and configuring unit tests. My last article also covered explaining about NUnit attributes used in writing unit tests. Please go through my last article of the series before following this article.

Roadmap

The following is the roadmap I have setup to learn WebAPI step by step,

• RESTful Day #1: Enterprise-level application architecture with Web APIs using Entity Framework, Generic Repository pattern and Unit of Work.
  
• RESTful Day #2: Inversion of control using dependency injection in Web APIs using Unity Container and Bootstrapper
  
• RESTful Day #3: Resolve dependency of dependencies using Inversion of Control and dependency injection in ASP.Net Web APIs with Unity Container and Managed Extensibility Framework (MEF)
  
• RESTful Day #4: Custom URL Re-Writing/Routing using Attribute Routes in MVC 4 Web APIs
  
• RESTful Day #5: Basic Authentication and Token-based custom Authorization in Web APIs using Action Filters
  
• RESTful Day #6: Request logging and Exception handing/logging in Web APIs using Action Filters, Exception Filters and NLog
  
• RESTful Day #7: Unit Testing and Integration Testing in WebAPI using NUnit and Moq framework (Part1)
  
• RESTful Day #8: Unit Testing and Integration Testing in WebAPI using NUnit and Moq framework (Part 2)
  
• RESTful Day #9: Extending OData support in ASP.NET Web APIs

I’ll purposely use Visual Studio 2010 and .net Framework 4.0 because there are few implementations that are very hard to find in .Net Framework 4.0, but I’ll make it easy by showing how we can do it.

Setup Solution

When you take the code base from my last article and open it in visual studio, you’ll see the project structure something like as shown in the below image,



The solution contains the WebAPI application and related projects. There are two newly added projects namedBusinessServices.Tests and TestHelper.We’ll use TestHelper project and its classes for writing WebAPI unit tests in the same way we used it for writing business services unit tests.

Testing WebAPI

Step 1: Test Project

Add a simple class library in the existing visual studio and name it ApiController.Tests. Open Tools->Library Packet Manager->Packet manager Console to open the package manager console window. We need to install same packages as we did for business services before we proceed.



Step 2: Install NUnit package.

In package manager console, select ApiController.Tests as default project and write command “Install-Package NUnit –Version 2.6.4”. When you run the command, it says NUnit is already installed, that’s because we installed this package for BusinessServices.Tests project, but doing this again for a new project (in our case it is ApiController.Tests) will not install it again but add a reference to nunitframework library and mark an entry in packages.config for ApiController. Tests project.



After it's  successfully installed, you can see the dll reference in project references i.e. nunit.framework,

Step 3: Install Moq framework

Install the framework on the same project in the similar way as explained in Step 2. Write command “Install-Package Moq”.



Step 4: Install Entity Framework

Install-Package EntityFramework–Version 5.0.0



Step 5: Newtonsoft.Json

Json.NET is a popular high-performance JSON framework for .NET. We’ll use it for serializing/de-serializing request and responses.

Install-Package Newtonsoft.Json -Version 4.5.11



Our packages.config i.e. automatically added in the project looks like,

<?xmlversion="1.0"encoding="utf-8"?>
    <packages>
        <packageid="EntityFramework" version="5.0.0" targetFramework="net40" />
        <packageid="Moq" version="4.2.1510.2205" targetFramework="net40" />
        <packageid="Newtonsoft.Json" version="4.5.11" targetFramework="net40" />
        <packageid="NUnit" version="2.6.4" targetFramework="net40" />
    </packages>

Step 6: References

Add references of BusinessEntities, BusinessServices, DataModel, TestsHelper, WebApi project to this project.



ProductControllerTests

We’ll start with setting up the project and setting up the pre-requisites for tests and gradually move on to actual tests.

Tests Setup

Add a new class named ProductControllerTest.csin ApiController.Testsproject.

Declare variables

Define the private variables that we’ll use in the class to write tests,

#region Variables

privateIProductServices _productService;
privateITokenServices _tokenService;
privateIUnitOfWork _unitOfWork;
privateList<Product> _products;
privateList<Token> _tokens;
privateGenericRepository<Product> _productRepository;
privateGenericRepository<Token> _tokenRepository;
privateWebApiDbEntities _dbEntities;
privateHttpClient _client;

privateHttpResponseMessage _response;
privatestring _token;
privateconststringServiceBaseURL = "http://localhost:50875/";

#endregion

Variable declarations are self-explanatory where _productService will hold mock for ProductServices, _tokenService will hold mock for TokenServices, _unitOfWork for UnitOfWork class, _products will hold dummy products from DataInitializer class of TestHelper project, __tokens will hold dummy tokens from DataInitializer class of TestHelper project ,_productRepository, tokenRepositoryand _dbEntities holds mock for Product Repository ,Token Repository and WebAPIDbEntities from DataModel project respectively.

Since WebAPI is supposed to return response in HttpResponse format so _response is declared to store the returned response against which we can assert._token holds the token value after successful authentication._client and ServiceBaseURL may not be required in this article’s context, but you can use them to write integration tests that purposely uses actual API URL’s and test on actual database.

Write Test Fixture Setup

Write test fixture setup method with [TestFixtureSetUp] attribute at the top, this method runs only one time when tests are executed.

[TestFixtureSetUp]
publicvoid Setup()
{
    _products = SetUpProducts();
    _tokens = SetUpTokens();
    _dbEntities = newMock < WebApiDbEntities > ().Object;
    _tokenRepository = SetUpTokenRepository();
    _productRepository = SetUpProductRepository();
    varunitOfWork = newMock < IUnitOfWork > ();
    unitOfWork.SetupGet(s => s.ProductRepository).Returns(_productRepository);
    unitOfWork.SetupGet(s => s.TokenRepository).Returns(_tokenRepository);
    _unitOfWork = unitOfWork.Object;
    _productService = newProductServices(_unitOfWork);
    _tokenService = newTokenServices(_unitOfWork);
    _client = newHttpClient
    {
        BaseAddress = newUri(ServiceBaseURL)
    };
    vartokenEntity = _tokenService.GenerateToken(1);
    _token = tokenEntity.AuthToken;
    _client.DefaultRequestHeaders.Add("Token", _token);
}

The purpose of this method is similar to that of method we wrote for business services.hereSetupProducts() will fetch the list of dummy products and SetupTokens() will get the list of dummy tokens. We will try to setup mock for Token and Product repository as well, and after that mock UnitOfWork and set it up against already mocked token and product repository._prdouctService and _tokenService are the instances of ProductService and TokenService respectively, both initialized with mocked Unit of Work.

Following is the line of code that I would like to explain more,

vartokenEntity = _tokenService.GenerateToken(1);
_token = tokenEntity.AuthToken;
_client.DefaultRequestHeaders.Add("Token", _token);

In the above code we are initializing the _client i.e. HttpClient with Token value in request header. We are doing this because, if you remember about the security (Authentication and Authorization) we implemented in Product Controller, which says no request will be entertained unless it is authorized i.e. contains an authentication token in its header. So here we generate the token via TokenService’s GenerateToken() method, passing a default used id as “1”, and use that token for authorization. We require this only to perform integration testing as for unit tests we would directly be calling controller methods from our unit tests methods, but for actual integration tests you’ll have to mock all pre-conditions before calling an API endpoint.

SetUpProducts():

privatestaticList < Product > SetUpProducts()
{
    varprodId = newint();
    var products = DataInitializer.GetAllProducts();
    foreach(Product prod in products)
    prod.ProductId = ++prodId;
    return products;
}

SetUpTokens():

privatestaticList < Token > SetUpTokens()
{
    vartokId = newint();
    var tokens = DataInitializer.GetAllTokens();
    foreach(Tokentokin tokens)
    tok.TokenId = ++tokId;
    return tokens;
}

Write Test Fixture Tear Down

Unlike [TestFixtureTearDown]t ear down is used to de-allocate or dispose the objects.

Following is the code for teardown.

[TestFixtureTearDown]
publicvoidDisposeAllObjects()
{
    _tokenService = null;
    _productService = null;
    _unitOfWork = null;
    _tokenRepository = null;
    _productRepository = null;
    _tokens = null;
    _products = null;
    if(_response != null) _response.Dispose();
    if(_client != null) _client.Dispose();
}

Write Test Setup

In this case Setup is only required if you write integration test. So you can choose to omit this.

[SetUp]
publicvoidReInitializeTest()
{
   _client = newHttpClient{ BaseAddress = newUri(ServiceBaseURL) };
   _client.DefaultRequestHeaders.Add("Token", _token);
}

Write Test Tear down

Test [TearDown] is invoked after every test execution is complete.

[TearDown]
publicvoidDisposeTest()
{
    if(_response != null) _response.Dispose();
    if(_client != null) _client.Dispose();
}

Mocking Repository

I have created a method SetUpProductRepository() to mock Product Repository and assign it to _productrepository in ReInitializeTest() method and SetUpTokenRepository() to mock TokenRepository and assign that to _tokenRepository in ReInitializeTest() method.

SetUpProductRepository():

privateGenericRepository < Product > SetUpProductRepository()
{
    // Initialise repository
    varmockRepo = newMock < GenericRepository < Product >> (MockBehavior.Default, _dbEntities);
    // Setup mocking behavior
    mockRepo.Setup(p => p.GetAll()).Returns(_products);
    mockRepo.Setup(p => p.GetByID(It.IsAny < int > ())).Returns(newFunc < int, Product > (id => _products.Find(p => p.ProductId.Equals(id))));
    mockRepo.Setup(p => p.Insert((It.IsAny < Product > ()))).Callback(newAction < Product > (newProduct =>
    {
        dynamicmaxProductID = _products.Last().ProductId;
        dynamicnextProductID = maxProductID + 1;
        newProduct.ProductId = nextProductID;
        _products.Add(newProduct);
    }));
    mockRepo.Setup(p => p.Update(It.IsAny < Product > ())).Callback(newAction < Product > (prod =>
    {
        varoldProduct = _products.Find(a => a.ProductId == prod.ProductId);
        oldProduct = prod;
    }));
    mockRepo.Setup(p => p.Delete(It.IsAny < Product > ())).Callback(newAction < Product > (prod =>
    {
        varproductToRemove = _products.Find(a => a.ProductId == prod.ProductId);
        if(productToRemove != null) _products.Remove(productToRemove);
    }));
    // Return mock implementation object
    returnmockRepo.Object;
}

SetUpTokenRepository():

privateGenericRepository < Token > SetUpTokenRepository()
{
    // Initialise repository
    varmockRepo = newMock < GenericRepository < Token >> (MockBehavior.Default, _dbEntities);
    // Setup mocking behavior
    mockRepo.Setup(p => p.GetAll()).Returns(_tokens);
    mockRepo.Setup(p => p.GetByID(It.IsAny < int > ())).Returns(newFunc < int, Token > (id => _tokens.Find(p => p.TokenId.Equals(id))));
    mockRepo.Setup(p => p.Insert((It.IsAny < Token > ()))).Callback(newAction < Token > (newToken =>
    {
        dynamicmaxTokenID = _tokens.Last().TokenId;
        dynamicnextTokenID = maxTokenID + 1;
        newToken.TokenId = nextTokenID;
        _tokens.Add(newToken);
    }));
    mockRepo.Setup(p => p.Update(It.IsAny < Token > ())).Callback(newAction < Token > (token =>
    {
        varoldToken = _tokens.Find(a => a.TokenId == token.TokenId);
        oldToken = token;
    }));
    mockRepo.Setup(p => p.Delete(It.IsAny < Token > ())).Callback(newAction < Token > (prod =>
    {
        vartokenToRemove = _tokens.Find(a => a.TokenId == prod.TokenId);
        if(tokenToRemove != null) _tokens.Remove(tokenToRemove);
    }));
    // Return mock implementation object
    returnmockRepo.Object;
}

Unit Tests



All set now, and we are ready to write unit tests for ProductController. We’ll write a test to perform all the CRUD operations and all the action exit points that are part of ProductController.

1. GetAllProductsTest ()

Our ProductService in BusinessServices project contains a method named GetAllProducts (), following is the implementation,

[Test]
publicvoid GetAllProductsTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Get,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/all")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    _response = productController.Get();
    varresponseResult = JsonConvert.DeserializeObject < List < Product >> (_response.Content.ReadAsStringAsync().Result);
    Assert.AreEqual(_response.StatusCode, HttpStatusCode.OK);
    Assert.AreEqual(responseResult.Any(), true);
    var comparer = newProductComparer();
    CollectionAssert.AreEqual(responseResult.OrderBy(product => product, comparer), _products.OrderBy(product => product, comparer), comparer);
}

Let me explain the code step by step. We start code by creating an instance of ProductController and initialize the Request property of controller with a   new request message stating calling http method as GET and initialize the RequestUri with base hosted service URL and appended with actual end point of the method. Initializing RequestUri is not necessary in this case but will help you if you test actual service end point. In this case we are not testing actual endpoint but the direct controller method.

HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration() line adds default httpconfiguration to HttpConfigurationKey necessary for controller instance instantiation.

_response = productController.Get();line calls the Get() method of controller that fetches all the products from dummy _products list. Since the return type of the method was an http response message, we need to parse it to get the JSON result sent from the method. All the transactions from API’s should ideally happen in form of JSON or XML only.This helps client to understand the response and its result set. We de-serialize the object we got from _response using NewtonSoft library into a list of products. That means the JSON response is converted to List<Product> for better accessibility and comparison. Once done with JSON to List object conversion, I have put three asserts to test the result.
Assert.AreEqual(_response.StatusCode, HttpStatusCode.OK); line checks the http status code of the response, the expected is HttpStatusCode.OK.

Second assert i.e. Assert.AreEqual(responseResult.Any(), true); checks that we have got the items in the list or not. Third assert is the actual confirmation assert for our test that compares each product from the actual product list to the returned product list.



We got both the list, and we need to check the comparison of the lists, I just pressed F5 and got the result on TestUI as,



This shows our test is passed, i.e. the expected and returned result is same.

2. GetProductByIdTest()

This unit test verifies if the correct result is returned if we try to invoke GetProductById() method of product controller.

[Test]
publicvoidGetProductByIdTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Get,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/productid/2")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    _response = productController.Get(2);
    varresponseResult = JsonConvert.DeserializeObject < Product > (_response.Content.ReadAsStringAsync().Result);
    Assert.AreEqual(_response.StatusCode, HttpStatusCode.OK);
    AssertObjects.PropertyValuesAreEquals(responseResult, _products.Find(a => a.ProductName.Contains("Mobile")));
}

I have used a sample product id “2” to test the method. Again we get the result in JSON format inside HttpResponse that we de-serialize. First assert compares for the status code and second assert makes use of AssertObject class to compare the properties of the returned product with the actual “mobile” named product having product id as 2 from the list of products.





Testing Exceptions from WebAPI

NUnit provides flexibility to even test the exceptions. Now if we want to unit test the alternate exit point for GetProductById() method i.e. an exception what should we do? Remember it was easy to test the alternate exit point for business services method because it returned null. Now in the case of exception, NUnit provides an attribute ExpectedException. We can define the type of exception expected to be returned from the method call. Like if I make a call to the same method with wrong id, the expectation is that it should return an exception with ErrorCode 1001 and an error description telling "No product found for this id.".

So in our case the expected exception type is ApiDataException(got it from controller method). Therefore we can define the Exception attribute as [ExpectedException("WebApi.ErrorHelper.ApiDataException")] and call the controller method with wrong id. But there is an alternate way to assert the exception. NUnit also provides us flexibility to assert the exception by Assert.Throws. This statement asserts the exception and returns that particular exception to the caller.Once we get that particular exception we can assert it with its ErrorCode and ErrorDescription or on whatever property you want to.

3. GetProductByWrongIdTest()

[Test]
//[ExpectedException("WebApi.ErrorHelper.ApiDataException")]
publicvoidGetProductByWrongIdTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Get,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/productid/10")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    var ex = Assert.Throws < ApiDataException > (() => productController.Get(10));
    Assert.That(ex.ErrorCode, Is.EqualTo(1001));
    Assert.That(ex.ErrorDescription, Is.EqualTo("No product found for this id."));
}

In the above code, I have commented out the Exception attribute approach and followed the alternate one.

I called the method with wrong id (that does not exist in our product list) in the statement,

var ex = Assert.Throws<ApiDataException>(() =>productController.Get(10));

The above statement expects ApiDataException and stores the returned exception in “ex”.

Now we can assert the “ex” exception properties like ErrorCode and ErrorDescription with the actual desired result.





4. GetProductByInvalidIdTest ()

Another exit point for the same method is that if request for a product comes with an invalid it then an exception is thrown. Let’s test that method for this scenario,

[Test]
// [ExpectedException("WebApi.ErrorHelper.ApiException")]
publicvoidGetProductByInvalidIdTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Get,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/productid/-1")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    var ex = Assert.Throws < ApiException > (() => productController.Get(-1));
    Assert.That(ex.ErrorCode, Is.EqualTo((int) HttpStatusCode.BadRequest));
    Assert.That(ex.ErrorDescription, Is.EqualTo("Bad Request..."));
}

I passed an invalid id i.e. -1 to the controller method and it throws an exception of type ApiException with ErrorCode equal to HttpStatusCode.BadRequest and ErrorDescription equal to “bad Request…”.



Test result,



i.e. Passed. Other tests are very much of same kind like I explained.

5. CreateProductTest ()

///<summary>
///Create product test
///</summary>
[Test]
publicvoidCreateProductTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Post,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/Create")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    varnewProduct = newProductEntity()
    {
        ProductName = "Android Phone"
    };
    varmaxProductIDBeforeAdd = _products.Max(a => a.ProductId);
    newProduct.ProductId = maxProductIDBeforeAdd + 1;
    productController.Post(newProduct);
    varaddedproduct = newProduct()
    {
        ProductName = newProduct.ProductName, ProductId = newProduct.ProductId
    };
    AssertObjects.PropertyValuesAreEquals(addedproduct, _products.Last());
    Assert.That(maxProductIDBeforeAdd + 1, Is.EqualTo(_products.Last().ProductId));
}

6. UpdateProductTest ()

///<summary>
/// Update product test
///</summary>
[Test]
publicvoidUpdateProductTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Put,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/Modify")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    varfirstProduct = _products.First();
    firstProduct.ProductName = "Laptop updated";
    varupdatedProduct = newProductEntity()
    {
        ProductName = firstProduct.ProductName, ProductId = firstProduct.ProductId
    };
    productController.Put(firstProduct.ProductId, updatedProduct);
    Assert.That(firstProduct.ProductId, Is.EqualTo(1)); // hasn't changed
}

7. DeleteProductTest ()

///<summary>
/// Delete product test
///</summary>
[Test]
publicvoidDeleteProductTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Put,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/Remove")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    intmaxID = _products.Max(a => a.ProductId); // Before removal
    varlastProduct = _products.Last();
    // Remove last Product
    productController.Delete(lastProduct.ProductId);
    Assert.That(maxID, Is.GreaterThan(_products.Max(a => a.ProductId))); // Max id reduced by 1
}

8. DeleteInvalidProductTest ()

///<summary>
/// Delete product test with invalid id
///</summary>
[Test]
publicvoidDeleteProductInvalidIdTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Put,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/remove")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    var ex = Assert.Throws < ApiException > (() => productController.Delete(-1));
    Assert.That(ex.ErrorCode, Is.EqualTo((int) HttpStatusCode.BadRequest));
    Assert.That(ex.ErrorDescription, Is.EqualTo("Bad Request..."));
}

9. DeleteProductWithWrongIdTest ()

///<summary>
/// Delete product test with wrong id
///</summary>
[Test]
publicvoidDeleteProductWrongIdTest()
{
    varproductController = newProductController(_productService)
    {
        Request = newHttpRequestMessage
        {
            Method = HttpMethod.Put,
                RequestUri = newUri(ServiceBaseURL + "v1/Products/Product/remove")
        }
    };
    productController.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, newHttpConfiguration());
    intmaxID = _products.Max(a => a.ProductId); // Before removal
    var ex = Assert.Throws < ApiDataException > (() => productController.Delete(maxID + 1));
    Assert.That(ex.ErrorCode, Is.EqualTo(1002));
    Assert.That(ex.ErrorDescription, Is.EqualTo("Product is already deleted or not exist in system."));
}

All the above mentioned tests are self-explanatory and are more like how we tested BusinessServices. The idea was to explain how we write tests in WebAPI.Let’s run all the tests through NUnit UI.

Test through NUnit UI



Step 1: Launch NUnit UI. I have already explained how to install NUnit on the windows machine. Just launch the NUnit interface with its launch icon,



Step 2: Once the interface opens, click on File -> New Project and name the project as WebAPI.nunit and save it at any windows location.







Step 3: Now, click on Project-> Add Assembly and browse for ApiController.Tests.dll (The library created for your unit test project when compiled)





Step 4: Once the assembly is browsed, you’ll see all the unit tests for that test project gets loaded in the UI and are visible on the interface.



At the right hand side panel of the interface, you’ll see a Run button that runs all the tests of Api controller. Just select the node ApiController in the tests tree on left side and press Run button on the right side.



Once you run the tests, you’ll get green progress bar on right side and tick mark on all the tests on left side. That means all the tests are passed.In case any test fails, you’ll get cross mark on the test and red progress bar on right side.



But here, all of our tests are passed.



Integration Tests

I’ll give just an idea of what integration tests are and how can we write it. Integration test doesn’t run in memory. For WebAPI’s the best practice to write integration test is when the WebAPI is self hosted.You can try writing an integration test when you host an API, so that you you get an actual URL or endpoint of the service you want to test.The test is performed on actual data and actual services. Let’s proceed with an example. I have hosted my web api and I want to test GetAllProducts() method of WebAPI.My hosted URL for the particular controller action is: http://localhost:50875/v1/Products/Product/allproducts.

Now I know that I am not going to test my controller method through dll reference but I want to actually test its endpoint for which I need to pass an authentication token because that end point is secured and can not be authorized until I add a secure token to the Request header.Following is the integration test for GetAllProducts().

[Test]
publicvoidGetAllProductsIntegrationTest()
{
    #regionTo be written inside Setup method specifically
    for integration tests
    var client = newHttpClient
    {
        BaseAddress = newUri(ServiceBaseURL)
    };
    client.DefaultRequestHeaders.Add("Authorization", "Basic YWtoaWw6YWtoaWw=");
    MediaTypeFormatterjsonFormatter = newJsonMediaTypeFormatter();
    _response = client.PostAsync("login", null).Result;
    if(_response != null && _response.Headers != null && _response.Headers.Contains("Token") && _response.Headers.GetValues("Token") != null)
    {
        client.DefaultRequestHeaders.Clear();
        _token = ((string[])(_response.Headers.GetValues("Token")))[0];
        client.DefaultRequestHeaders.Add("Token", _token);
    }
    #endregion

    _response = client.GetAsync("v1/Products/Product/allproducts/").Result;
    varresponseResult = JsonConvert.DeserializeObject < List < ProductEntity >> (_response.Content.ReadAsStringAsync().Result);
    Assert.AreEqual(_response.StatusCode, HttpStatusCode.OK);
    Assert.AreEqual(responseResult.Any(), true);
}

I have used same class to write this test, but you should always keep your unit tests segregated from integration tests, so use another test project to write integration tests for web api. First we have to request a token and add it to client request,

var client = newHttpClient { BaseAddress = newUri(ServiceBaseURL) };
client.DefaultRequestHeaders.Add("Authorization", "Basic YWtoaWw6YWtoaWw=");
MediaTypeFormatterjsonFormatter = newJsonMediaTypeFormatter();
_response = client.PostAsync("login", null).Result;

if (_response != null&& _response.Headers != null&& _response.Headers.Contains("Token") && _response.Headers.GetValues("Token") != null)
{
   client.DefaultRequestHeaders.Clear();
   _token = ((string[])(_response.Headers.GetValues("Token")))[0];
   client.DefaultRequestHeaders.Add("Token", _token);
}

In the above code I have initialized the client with running service’s base URL i.e. http://localhost:50875. After initialization I am setting a default request header to call my login endpoint of Authentication controller to fetch valid token. Once the user logs in with his credentials he gets a valid token. To read in detail about security refer my article on security in web api. I have passed base 64 string of my credentials username: Akhil and password:Akhil for basic authentication.Once request gets authenticated, I get a valid token in _response.Headers that I fetch and assign to _token variable and add to client’s default header with this line of code,

_token = ((string[])(_response.Headers.GetValues("Token")))[0];

client.DefaultRequestHeaders.Add("Token", _token);

Then I am calling the actual service URL from the same client,

_response = client.GetAsync("v1/Products/Product/allproducts/").Result;

And we get the result as success. Follow the screen shots.

Step 1: Get Token,



We got the token: 4bffc06f-d8b1-4eda-b4e6-df9568dd53b1. Now since this is a real time test.This token should get saved in database. Let’s check.

Step 2: Check database,



We got the same token in database. It proves we are testing on real live URL.

Step 3: Check Response Result,



Here we got the response result with 6 products where first product id is 1 and product name is “Laptop”. Check the database for complete product list,



We get the same data. This proves our test is a success.



Likewise you can write more integration tests.

Difference between Unit tests and Integration tests

I’ll not write much, but wanted to share one of my good readings on this from this reference link.
 

Unit Testing	Integration Testing
Unit testing is a type of testing to check if the small piece of code is doing what it is supposed to do.	Integration testing is a type of testing to check if different pieces of the modules are working together.
Unit testing checks a single component of an application.	The behavior of integration modules is considered in the Integration testing.
The scope of Unit testing is narrow, it covers the Unit or small piece of code under test. Therefore while writing a unit test shorter codes are used that target just a single class.	The scope of Integration testing is wide, it covers the whole application under test and it requires much more effort to put together.
Unit tests should have no dependencies on code outside the unit tested.	Integration testing is dependent on other outside systems like databases, hardware allocated for them etc.
This is first type of testing is to be carried out in Software testing life cycle and generally executed by developer.	This type of testing is carried out after Unit testing and before System testing and executed by the testing team.
Unit testing is not further sub divided into different types.	Integration testing is further divided into different types as follows:
	Top-down Integration, Bottom-Up Integration and so on.
Unit testing is starts with the module specification.	Integration testing is starts with the interface specification.
The detailed visibility of the code is comes under Unit testing.	The visibility of the integration structure is comes under Integration testing.
Unit testing mainly focus on the testing the functionality of individual units only and does not uncover the issues arises when different modules are interacting with each other.	Integration testing is to be carried out to discover the the issues arise when different modules are interacting with each other to build overall system.
The goal of Unit testing is to test the each unit separately and ensure that each unit is working as expected.	The goal of Integration testing is to test the combined modules together and ensure that every combined moduleis working as expected.
Unit testing comes under White box testing type.	Integration testing is comes under both Black box and White box type of testing.

Table reference.

Conclusion



In this article we learned how to write unit tests for Web API controller and primarily on basic CRUD operations. The purpose was to get a basic idea on how unit tests are written and executed. You can add your own flavor to this that helps you in your real time project. We also learned about how to write integration tests for WebAPI endpoints. I hope this was useful to you. You can download the complete source code of this article with packages from GitHub.

Read more:

• C# and ASP.NET Questions (All in one)
• MVC Interview Questions
• C# and ASP.NET Interview Questions and Answers
• Web Services and Windows Services Interview Questions

For more technical articles you can reach out to CodeTeddy

My other series of articles:

• Learning MVC
• Learning OOP concepts with C#

Read more articles on ASP.NET:

• Using TempData, ViewData And ViewBag In ASP.NET MVC 5.0: Part 11  
• Language Converter Using Google Translator Plugin In ASP.NET