This is exactly what is happening on one of my projects as the integration tests are only validating the security setup of the endpoints to ensure that only allows users have data returned and all others get a 403 Forbidden error. However, if you look at the combined report, it is not clear what lines of business logic code is not actually being tested and can you lead you to believe that you have more test coverage than you actually do. The integration tests may not actually be looking in depth at the businesss logic like a unit test would. However, a lot of times the integration tests are looking more at things like security checks on the endpoints or making sure the returned view model is correct or validating how an exception looks coming back to the caller. So in a combined code coverage report, every line of code that the endpoint calls is considered covered. ![]() With the integration test since it start at the endpoint, that means it calls all of the business logic along the way. If we look at an ASP.NET Web Api, the integration test would call the REST endpoint while the unit test would only call a single method in the business logic. Integration Test: testing the whole flow of the application starting with what the user interfaces with (UI or Api endpoints) and dependencies are typically not mocked out. You are testing the smallest unit of work possible. Unit Test: testing the business logic and data layers of your application with dependencies mocked out. Why do we need seperate code coverage reports?īefore I dive into the reason the reporting may be higher than reality, lets define the difference between a unit test and integration test. In this post, we are going to look at how in TeamCity you can run multiple test builds to generate both individual reports and still have a combined report. The overall coverage is nice but when you have both unit tests and integration tests, or multiple test projects serving different purposes, there is a high potential that you are reporting lines of code being covered that were only called but not actually tested. You might be thinking why would you want to do this? Don’t you want to see the overall test coverage? In our previous post, we talked about how TeamCity automatically combines multiple dotCover outputs into a single code coverage report but what if we wanted to keep thoose reports seperate?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |