DEV Community: Taylor Howard

Generating code coverage from integration tests with dotCover

Taylor Howard — Fri, 31 Jan 2020 20:32:12 +0000

Sometimes your integration tests aren't written in the same language as your application (especially e2e tests) and it gets hard to collect code coverage for the main application. I currently have this exact issue where I have an application written in C# using dotnet core 3.1, and I have my integration tests written in JavaScript. It's really easy to get the code coverage for unit tests in C#, but it becomes a little harder when my tests aren't written in C#.

That's where dotCover comes in.

NOTE: dotCover is not free to use. They do have a trial, but otherwise you need a ReSharper Ultimate subscription for personal or commercial use. I'm personally a huge fan of JetBrains and already subscribe to their full suite of products.

First we'll download dotCover, and place it in our path. It will work in both Windows and Unix environments, and all the commands I will write here are for Windows. After extracting the file, I'm going to add to my path using the Edit System Environment Variables. If you set it up successfully, you should be able to run dotcover in PowerShell and see this output. If you're running on Unix, you might have to add +x to the dotCover.sh and you might need to call it from the terminal as dotCover.sh instead of just dotCover

Now that we have access to run dotcover, we can start our application with it and test against or (or just run against it to potentially see where we have dead code).

All the console commands can be found here.

First off we're going to start our set our application up to get ready to start with this command.

dotcover cover --targetExecutable="bin\Debug\netcoreapp3.1\win-x64\YourApplicationName.exe" --output="report.html" --reportType="HTML" --startInstance="1"

Let's go over the args one at a time.

--targetExecutable is the executable you want to test against. For me this is my Web Api.

--output is just that, it's the name of the file to open the coverage report. For now, report.html will suffice.

--reportType is also pretty simple. For me I like the pretty HTML it outputs so that's what I use. Here's the rest you can use HTML|JSON|XML|DetailedXML|NDependXML.

--startInstance="1" is going to set our application to be run by dotcover with the identifier 1. This is so that if we need to something before we start our application, we can. For me, I need to set up my JavaScript tests, so that's what I do here, but you can do whatever you need.

Now that our instance is prime and ready, we're ready to start our application via dotcover. This is done by the send command.

So we'll run dotcover send --Instance="1" --Command="Cover" which will start our app.

--Instance="1" is denote which instance we're sending it to

--Command="Cover" is to tell it to start

Next we can start our tests that run against our app. For me this would be a simple yarn start

After that's over we need to tell the runner that it's done and to output the files. All we have to do is send another command to our instance with dotcover send --Instance="1" --Command='GetSnapshotAndKillChildren"

It should say that it send the command successfully, and you should have your outputs!

Validating your TypeScript types

Taylor Howard — Thu, 30 Jan 2020 16:43:45 +0000

TypeScript is a fantastic language. It gives lift to the JS language by allowing pseduo-typing making it easier to understand what's coming in and out. Let's look at a simple TS example with the idea of retrieving a user from the database.

interface IUser {
  firstName: string;
  middleName: string;
  lastName: string;
  birthday: Date;
}

class UserRepository {
  private readonly db: any; // this is some way to access the DB, not important

  constructor(db: any) {
    this.db = db;
  }

  async getUsers(): IUser[] {
    const users: IUser[] = await this.db<IUser>.getUsers();
    return users;
  }
}

Looking at this, we have a simple user object and return all of them from the database. It looks like there's only 4 properties and all are required. There's a glaring issue here, though. What if the database type doesn't match the TypeScript type? Let's say for example in the database, middleName isn't required, and you need to print out the whole name of the user. Not everyone has a middle name, so it makes sense that the db doesn't require it. With the wrong type, when you go in and need to implement this function, you'd probably do something like this.

const getFullName = (user: IUser): string =>
 `${user.firstName} ${user.middleName} ${user.lastName}`;

But this won't work. What if my name is just John Doe? Then my full name would look like this when printed John null Doe. While null is a cool middle name, that's not my name! The problem is that in TypeScript the types don't exist at runtime. Let's look at the output from the TS compiler for our simple function.

interface IUser {
    firstName: string;
    middleName: string;
    lastName: string;
    birthday: Date;
}

const getFullName = (user: IUser): string => 
`${user.firstName} ${user.middleName} ${user.lastName}`

gets compiled down into

"use strict";
const getFullName = (user) => 
`${user.firstName} ${user.middleName} ${user.lastName}`;

which means that our types aren't real and only help us if they're right.

What we can do is create objects that are required to have the correct type at runtime. Here I'm going to use the library Joi, but there are others that accomplish the same goal. What Joi will do is validate an object that comes in according to the rules we set.

Let's create an object that will be safe for us at runtime by first creating a Joi schema that will mimic what our IUser interface looks like.

import * as Joi from 'joi';

const userSchema = Joi.object({
  firstName: Joi.string().required(),
  middleName: Joi.string().allow(null),
  lastName: Joi.string().required(),
  birthday: Joi.date().required()
});

It's a simple schema, but let's go through it at a high level. Basically all we have 3 required properties (firstName, lastName, birthday) and one that isn't required. The allow(null) is so that Joi doesn't complain when the property exists but is null. We see that firstName, middleName, lastName, and birthday are all strings while birthday is a date. There's plenty of built in functionality there that I won't go over since it's extraordinarily powerful, but that's the gist of this simple schema. If we passed 1 into firstName, it would fail the schema validation.

Let's first write the validation method.

import * as Joi from 'joi';

const validateObject = (schema: Joi.schema, data: any): any => {
  const res = schema.validate(data, { stripUnknown: true });

  if(res.error) {
    throw new Error('failed validation');
  }

  return res.value;
}

Nothing fancy. If the validator from Joi errors, we throw our own error. The res.value is the object that has been validated. The { stripUnknown: true } we passed into the validate method will remove any unknown keys so that we only get what we validated back from the res.value.

Next up lets create our actual User class that has the validated properties assigned.

class User {
  public readonly firstName: string;
  public readonly middleName: string | null;
  public readonly latsName: string;
  public readonly birthDay: Date;

  private readonly schema =  Joi.object({
    firstName: Joi.string().required(),
    middleName: Joi.string().allow(null),
    lastName: Joi.string().required(),
    birthday: Joi.date().required()
  });

  constructor(objToValidate: any) {
    const res = validateObject(obj, this.schema);
    this.firstName = res.firstName;
    this.middleName = res.middleName;
    this.lastName = res.lastName;
    this.birthDate = res.date;
  }
}

As you can see, we have an object with our 4 properties that are readonly. That way we can stop people from manipulating them without going through the validation. A potential idea could be to add setters for them that would go through the validation additionally, but I'll leave that to you to expand upon :) After we validate the object in the constructor, we assign the properties from the validation to our properties. As said above, since we stripped the properties and our keys in our Joi schema match we can use the result from the validation to assign the properties.

Now here's our initial example with our new User type.

class UserRepository {
  private readonly db: any; // this is some way to access the DB, not important

  constructor(db: any) {
    this.db = db;
  }

  async getUsers(): User[] {
    const users: any[] = await this.db.getUsers();
    return users.map(u => new User(u));
  }
}

There's a little problem here, in that we still have our public properties on our object that can be wrong. If we were to omit the | null from our middle name, we'd be in the same predicament as earlier. What this does do for us is validate the object is required to pass the schema we have, meaning that we have the object shape we expect, and we have. A typical case would be that in our database schema we initially required middleName, but change our DB schema to allow it to be null. This could cause hidden bugs because our type isn't there at runtime, but our validation is. Additionally, we can validate way more than just simple strings and dates. We could do things like validate that our ids are valid uuids or any other number of rules, allowing us to avoid potential bugs.

My favorite alternative to Joi would have to be class-validator.