none
Unit Testing Code Coverage for WebService Method including async methods RRS feed

  • Question

  • Hi All, I just need information about code coverage of webservice method that includes Async Methods as well.

    Suppose, I have one method written in WebService, MethodOne(string Value) and I have written TestMethod to check code coverage for this method,

    When I run Test and check in code coverage, it showing me something like

    MethodOne(string) 100%

    MethodOneAsync(string) 0%

    MethodOneAsync(string,object) 0%

    so because of Asynchronize methods, I can not understand the actual code coverage of my projects, I want to cover these kind of methods as well in my code coverage.

    Any guidance or article would be greatly appreciate.

    Thanks


    Friday, December 20, 2013 7:19 AM

Answers

  • You would need to write a unit test for the async version as well.  However I generally recommend that you don't try for 100% code coverage.  It gives a false positive that your code works correctly.  That isn't true necessarily.  All it guarantees is that all the code has been executed as part of (all) unit testing. 

    You should test the functionality of your code.  If you do that then you'll likely get 80%+ code coverage.  Unless you explicitly write extra tests you'll be skipping paths such as exception paths and whatnot.  At that point though you're testing implementation and not behavior in many cases. This also means that if you modify your implementation later on then you'll likely break unit tests (even though the behavior hasn't changed).

    I personally find the best unit test is the one that doesn't need to be written.  If all your async method does is call the sync version then there really isn't any functionality to test (that hasn't already been tested) so you're just writing a unit test for coverage purposes.  However if your async method has its own logic and behaves differently then unit testing the behavior does make sense.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by ikhan.pathan Saturday, December 21, 2013 10:17 AM
    Friday, December 20, 2013 6:28 PM
    Moderator

All replies

  • I have written following code that also doesn't cover async methods

    public async void TestMethod1Async()
            {
                bool isValue = await System.Threading.Tasks.TaskEx.Run(() => target.IsAccountDisabled(Guid.NewGuid()));
                Assert.IsFalse(isValue);
            }

    Do I have to write unit test for synchronize method and asynchronized method differently? Is that possible that to write unit test for synchronize method that covers asynchronize method as well?

    Friday, December 20, 2013 9:32 AM
  • You would need to write a unit test for the async version as well.  However I generally recommend that you don't try for 100% code coverage.  It gives a false positive that your code works correctly.  That isn't true necessarily.  All it guarantees is that all the code has been executed as part of (all) unit testing. 

    You should test the functionality of your code.  If you do that then you'll likely get 80%+ code coverage.  Unless you explicitly write extra tests you'll be skipping paths such as exception paths and whatnot.  At that point though you're testing implementation and not behavior in many cases. This also means that if you modify your implementation later on then you'll likely break unit tests (even though the behavior hasn't changed).

    I personally find the best unit test is the one that doesn't need to be written.  If all your async method does is call the sync version then there really isn't any functionality to test (that hasn't already been tested) so you're just writing a unit test for coverage purposes.  However if your async method has its own logic and behaves differently then unit testing the behavior does make sense.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by ikhan.pathan Saturday, December 21, 2013 10:17 AM
    Friday, December 20, 2013 6:28 PM
    Moderator
  • Thanks for valuable feedback
    Saturday, December 21, 2013 10:18 AM