Unit Tests and VSTS. How to configure team services build with different testing frameworks.

Configuring build just to check if code is compiling - it's boring and obvious, just create build, choose repository and add build solution task. That's it. This kind of build is useful for checking code integrity eg. after automatic merge. But it's much better to have also unit tests and run them, you can be more or less sure that when tests are green then the merge didn't broke anything vital.


I prepared solution with very simple class and method that can be tested. The method adds to numbers. The class is in class library so it cannot be run by itself. 
Additionally I created number of projects with different unit tests frameworks. To show the most basic test definitions. There are may unit testing frameworks because they act differently in build. 
MsBuild and NUnit 2.6 doesn't need any additional build configuration, but no one wants to use them any more. NUnit 3 and xUnit on the contrary, those frameworks needs adapters/runners.

Adapter/runner corresponding to unit test framework must be included in solution as a NuGet package. This provides the binaries that will enable run tests with default Visual Studio test runner. You don't have to include adapter in every test project, it is important to get the package that can be reused.  For xUnit the package is xunit.runner.visualstudio and for NUnit it's NUnitTestAdapter.

Solution you can get from GitHub or just watch short intro:

Now lets create a build definition. Ready build definition you can get here. You can download this definition end import it in your Vsts. I'm using old Vsts look because it's more brief and presents more data on one screenshot.

For MsTest and NUnit 2.6 no additional configuration is required.
For  NUnit 3 and xUnit there are already adapters in the solution so they will be restored to NuGet packages folder. Packages are restored into **\packages. 
I'm using git so the final location is $(Build.Repository.LocalPath)\packages.
And this information must be presented to "Path to Custom Test Adapters" option of test task so the build can locate runners and use them.


Popular posts from this blog

Azure post deployment scripts

Image
Let's do a trick. After deploying application (that was easy with Ftp or Git ) it would be nice to take some action. For example send an email, or write release notes to release page. I will do much fancier thing - I will write some text to console output.
Read more

Mobile view lifecycle. Fixing Xamarin.Forms Page lifecycle

Image
For mobile applications the highest priority is user. What user can see and interacts with. Application should react not only on user interacting with it but also user interacting with operating system. That's why not only application has it's own lifecycle but also "view" has it's own lifecycle. In Android view is represented by activity, or a fragment (the right side of android diagram). In iOS view has it's own set of lifecycle methods. In both cases view has the information that application(in this case view itself)  is being suspended and reactivated. View know quite a lot about outside world and view lifecycle is very similar to application lifecycle. Compare below first application and then view lifecycle diagrams: In Android view is represented by activity, or a fragment (the right side of android diagram). In iOS view has it's own set of lifecycle methods. In both cases view has the information that application(in this case view itself)  is
Read more

Mobile application life-cycle Android vs iOS vs Xamarin.Forms

Image
Lifecycle. One of the most common recruitment questions. No matter what technology you work with this is something that should be well known and understood. It's good to know how application behaves, what it is allowed depending on its state and when to react on specific lifecycle events. In mobile world lifecycle is even more complicated because there is no 1 answer but 3 in this case: Android. iOS. Xamarin.Forms. I use also Xamarin.iOS event names in my diagrams, but the sequence is the same. Lifecycle is the definition when your application have access to resources and when react on state change. For mobile the biggest priority is what user can see and interacts with, so active application have priority in using system resources. System has limited pool of resources, so  applications running in background (not visible to user) is limited by system in how much resources can it use and also system decides when application needs to release all resources (be closed/killed/end o
Read more