unit-testing

Publish Core XUnit Test Results in VSTS

Posted on by trailmax

Following my previous post, I’m building Asp.Net Core web application and I’m running my tests in XUnit. Default VSTS template for Asp.Net Core application runs the tests but it does not publish any results of test execution, so going into Tests results panel can be sad:

And even if you have a task that publishes test results after dotnet test, you will not get far.

As it turns out command dotnet test does not publish any xml files with tests execution results. That was a puzzle for me.

Luckily there were good instructions on XUnit page that explained how to do XUnit with Dotnet Core properly. In *test.csproj file you need to add basically the following stuff:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="xunit" Version="2.3.0-beta2-build3683" />
    <DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0-beta2-build3683" />
  </ItemGroup>

</Project>

Continue reading →

Database Integration Tests in Visual Studio Team Services and Cake Build

Posted on by trailmax

I’m a big fan of unit tests. But not everything can and should be unit tested. Also I do love CQRS architecture – it provides awesome separation of read and writes and isolates each read from the next read via query classes. Usually my queries are reading data from a database, though they can use any persistence i.e. files. About 90% of my queries are run against database with Entity Framework or with some micro ORM (currently I’m a fan of PetaPoco, though Dapper is also grand).

And no amount of stubs/mocks or isolating frameworks will help you with testing your database-access layer without actual database. To test your database-related code you need to have a database. Full stop, don’t even argue about this. If you say you can do unit-tests for your db-layer, I say your tests are worth nothing.

A while ago I’ve blogged about integration tests and that article seems to be quite popular – in top 10 by visitors in the last 2 years. So I decided to write an update.

Continue reading →

Why you should write unit tests

Posted on by trailmax

One of the questions I have to answer frequently (mostly question myself) is “why should I write unit tests?”. One of the simplest answers it “They help you discover bugs”.

When you are writing unit test, you should not think about the internals of your methods, but rather about results you would like to get from that method. Kind of black-box testing. If you are not doing TDD, it also can help if you write tests the next day, when implementation details of your methods are not so fresh in your head.

Today I discovered yet another problem in the implementation of RavenDBMembershipProvider: most of the code is not mine there, but I’m writing tests and aim close to 100% coverage. Now in the main class only a few lines of code are not covered. When I started writing last few tests for these lines, I have discovered a problem. Without tests that would possibly be never discovered.. and possibly could lead to a security vulnerability.

WRITE YOUR TESTS!