#Teamcity artifact paths code#

A build that has a dependency on the unit and integration test builds and takes the artifact for each of those builds to do a combined report.Integration test build to generate the individual report with the snapshot as a build artifact.

Unit test build to generate the individual report with the snapshot as a build artifact.Implementationįor our TeamCity build, we are going to set up 3 builds in total for this work. However, we do still like to have the combine report just for reporting purposes to get an overall picture of how we are doing.

#Teamcity artifact paths code#

So for us, it was very important to have the individual code coverage reports for unit tests and integration tests so that we could easily see where we have gaps in the unit test that are testing our business logic. However, for authorization success, it call as the way through all the layers of the application and returns data which makes it look like we tested our business logic when is reality we did not run a single tests against that logic in our integration test. For the 403 Forbidden error, the code coverage is spot on as the code stops within the endpoint and returns an error message. 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?