DEV Community: Dino Kacavenda

Easily Create Mock Data for Unit Tests

Dino Kacavenda — Thu, 25 Feb 2021 13:02:13 +0000

In this article, I will show you how to improve your unit tests with the use of the builder design pattern. I will use it to solve one of the hardest problems when writing unit tests: creating mock data. Mock data created using the builder pattern will:

be easy to read and understand
be reusable
ensure mock data doesn't break the domain rules

I will be using C# in the following example, but the principles can easily be applied to other languages.

Initial Solution

First I will show you a solution that doesn't use the builder pattern. For this example, we will be mocking a User object that has the following definition:

public class User
{
  public int Id { get; set; }
  public string Name { get; set; }
  public string Email { get; set; }
  public DateTime DateOfBirth { get; set; }
  public bool? IsDeleted { get; set; }
  public DateTime? DeletedOn { get; set; }
}

Let's create two mock User objects, where one object has only required properties (Id, Name, DateOfBirth, and Email), and another that mocks a deleted User:

var user = new User
{
  Id = 1,
  Name = "John Locke",
  DateOfBirth = new DateTime(2000, 1, 1),
  Email = "johnlocke@gmail.com"
 };

var deletedUser = new User
{
  Id = 2,
  Name = "Tom Sawyer",
  DateOfBirth = new DateTime(2000, 1, 1),
  Email = "tomsawyer@gmail.com",
  // only this property really matters for this mock
  IsDeleted = true
};

We see that with this approach we have to type a lot of code. Also, it is hard for the reader to notice what properties really matter for the specific test, and which are there because our object should always have them. We also need to be careful not to break specific domain rules (for example create 2 mock users with the same id).

If we added a new required property to the User object, we would need to add it to all of the mocks, otherwise, we might risk tests passing, when in fact, mock data is not valid. In the next section, we will create User mocks using the builder pattern and see how it improves the initial solution.

Builder Pattern

Builder pattern is a creational design pattern used for the easy creation of complex objects. Let's create a builder for the User object. We will start by creating a new class: MockUserBuilder (it is good to have consistent naming in your project. One that I recommend is Mock[entity name]Builder) and add a default constructor:

public class MockUserBuilder
{
    private static int _id = 1;

    private readonly User _user;
    public MockUserBuilder()
    {
        _user = new User
        {
            Id = _id,
            Name = $"John Locke {_id}",
            DateOfBirth = new DateTime(2000, 1, 1),
            Email = $"johnlocke{_id}@gmail.com"
        };

        _id++;
    }
}

In the constructor, we create a User object that is filled with mock data. This object needs to fulfill all the domain rules, so make sure you defined all the properties that are required. Also, we have a private static _id property, so every User will have a unique id.

Next, we will add helper methods that will be used to define specific properties of a User:

public class MockUserBuilder
{
    // ... our constructor

    public MockUserBuilder WithName(string name)
    {
        _user.Name = name;
        return this;
    }

    public MockUserBuilder WithEmail(string email)
    {
        _user.Email = email;
        return this;
    }

    public MockUserBuilder WithIsDeleted(DateTime? deletedOn)
    {
        _user.IsDeleted = true;
        _user.DeletedOn = deletedOn ?? DateTime.UtcNow;
        return this;
    }

   // methods for other properties

    public User Build() => _user;
}

All helper methods have a similar naming structure: With[PropertyName]. Every method is used to set a specific property, and it returns the MockUserBuilder so we can use the fluent syntax. This might seem like a lot of boilerplate code just to set some properties, but when you start writing your builders you don't need to add methods for every property immediately. I recommend you add only the properties you need for the specific tests you write, and gradually add the rest as you need them.

We can also group properties that are always set together. An example of this is the WithIsDeleted method. When a User is deleted, we always set both the IsDeleted flag and DeletedOn. By using the builder pattern we can guarantee that our mock data will always set these properties together, so we don't forget to set them in all places when manually creating mock objects (as in the example from the initial solution).

Let's use our builder to rewrite mocks from the initial solution:

var user = new MockUserBuilder()
    .Build();

var deletedUser = new MockUserBuilder()
    .WithName("Tom Sawyer")
    .WithEmail("tomsawyer@gmail.com")
    .WithIsDeleted()
    .Build();

We see that this solution is much more readable. For the first mock user, we didn't have to set required properties because they are automatically set inside MockUserBuilder. We could have simplified the deleted mock user if the specific name and email didn't matter, so it would have been even less code. The builder will guarantee each created user has a unique Id.

This pattern especially shines when testing some edge cases, for example we need two users with the same name:

var user1 = new MockUserBuilder()
    .WithName("Tom Sawyer")
    .Build();

var user2 = new MockUserBuilder()
    .WithName("Tom Sawyer")
    .Build();

Here it is very clear that we wanted mock objects with exactly the same name. If we didn't use the builder pattern we would need to specify all of the required properties and then it would be hard to notice the important ones.

Further Improvements

Builder from the previous section is very powerful by itself. If you want to further improve your builders, here are some additional tips that you can use.

Creating a Clone Method

Usually, when testing edge cases we create many mock objects that differentiate in a single property. If we need to set all of the properties they share, it is easy to miss what property was specific for a mock object. To solve this, we can create a clone method. This method will create a new builder from the existing one, and copy all the properties set on the initial entity. If you use an object-oriented language (like C#) you can put this method in an abstract class which will be inherited by the specific mock builders. One way to do a deep clone is to serialize and then deserialize the builder object (this way even non-primitive values will be correctly cloned).

public abstract class BaseMockBuilder<TBuilder, TEntity>
{
    // we need to add JsonProperty so the protected property is included
    [JsonProperty]
    protected TEntity entity { get; set; }

    public TBuilder CloneBuilder()
    {
        // serialize and then deserialize builder to create a deep clone of the builder
        // using Newtonsoft.Json
        var json = JsonConvert.SerializeObject(this);
        return JsonConvert.DeserializeObject<TBuilder>(json);
    }

    // we can even move Build to the base class now
    public TEntity Build() => entity;
}

And then we change the MockUserBuilder so it inherits from the BaseMockBuilder:

public class MockUserBuilder : BaseMockBuilder<MockUserBuilder, User>
{
    private static int _id = 1;

    // this is now defined in the base class
    private readonly User _user;

    // same as before, just rename _user to entity

Using a Fake Data Generator

In the previous example, we hard-coded values for the mock values. There is an excellent nuget package that can generate fake data that will resemble real data: Bogus. You can easily integrate Bogus, and use it inside the builder constructor for initial values.

Combining Builder Pattern with Object Mother Pattern

In our example, the builder always started creating mock data from the same blueprint (defined in the builder constructor). If we have several types of different object configurations, we can expand the builder to provide multiple initial configurations. Then we can use the defined methods for setting properties to customize these objects.

If we created a lot of deleted users, we can utilize the object mother pattern to create a separate blueprint for them:

private MockUserBuilder()
{
    entity = new User
    {
        Id = _id,
        Name = "John Locke",
        DateOfBirth = new DateTime(2000, 1, 1),
        Email = $"johnlocke{_id}@gmail.com"
    };

    _id++;
}

// new constructor for deleted user that uses the initial constructor
// and adds deleted properties
private MockUserBuilder(DateTime? deletedOn) : this()
{
    WithIsDeleted(deletedOn);
}

// method for creating our default builder
public static MockUserBuilder Create() => new MockUserBuilder();

// method for creating a deleted user builder
public static MockUserBuilder CreateDeletedUser(DateTime? deletedOn = null) => new MockUserBuilder(deletedOn);

Now we can use our separate factory methods to easily create different kinds of users:

var user = MockUserBuilder
    .Create()
    .WithEmail("mother@gmail.com")
    .Build();

var deletedUser = MockUserBuilder
    .CreateDeletedUser()
    .WithName("Tom Sawyer")
    .WithEmail("tomsawyer@gmail.com")
    .Build();

You can read more about this pattern here.

Conclusion

In this article, I showed you how to use the builder pattern to easily create mock data for your unit tests. Also, I provided you with ways to improve on the initial pattern. I hope you find this pattern useful and would like to hear in the comment section below if you are already familiar with it and which potential improvements have you made.

12 Tips for Writing Better Automated Tests

Dino Kacavenda — Tue, 02 Feb 2021 08:29:13 +0000

Automated tests are one of the core principles for writing maintainable code. When we have tests, we can refactor code without worrying we might break existing code. They also, help us catch bugs that would otherwise end up in production. Good tests can be compared to checkpoints that guide the developers throughout the entire process and provide them with reliable feedback if the code is working properly. However, it is not easy to write good tests. The worst feeling is when you have tests that start failing and are hard to debug (often we end up commenting them out). This causes developers (and project managers) to lose faith in the usefulness of testing.

In this post, I will give you some essential tips on how you can upgrade your testing game and hopefully inspire you to write some tests of your own.

Tips covered in this post:

Structure your tests
Extract setup from tests
Keep your tests simple
Do not test implementation details
Test naming
Tests are repeatable
Check that your tests are actually working
Avoid magic numbers or strings
Tests are code too
Integrate tests in your CI/CD process
Create documentation
Testing hero

Structure your tests

Developers love writing code, still most of the time we end up mainly reading it. This is especially true when dealing with test code. When a test fails(and it oftentimes does) we don't want to waste a lot of time trying to figure out what the test was supposed to do. We should focus on making tests more readable by using the AAA pattern:

Arrange -> setup your application state
Act -> execute the piece of code you want to test
Assert -> check that the new application state is what you expected after executing the code you were testing

It is great to visibly separate these parts by using comments or regions if your language supports them. If you are using Visual Studio Code you can use the #region to organize your code so that parts of the AAA pattern are visible:

Having a consistent structure in all of the tests, helps out developers look at test code more easily, and at a glance figure the important parts and debug them if necessary.

Extract setup from tests

Usually, the hardest thing to do when you are writing tests is mocking the state of your application so that you can run the code you want to test. In most situations when you analyze a particular test code, the biggest part will be the setup. That's why it is great to extract this setup in separate functions. This has certain benefits:

It allows us to name our setup so that the state we wanted to achieve is clear
It allows us to reuse our setup if we have multiple similar tests
Our test code is now cleaner and we can clearly see the aim of the test

Be careful when reusing extracted test setups. By reusing them in multiple tests, they will probably be extremely complex (since each test needs a specific application state). You also might break some existing tests by adding new lines of code into your setup just to avoid repeating previous steps. In those cases, it is better to break the DRY (do not repeat yourself) principle, and have multiple simple test setups than one complex. You can always create testing utilities that can be used to create application state in setups if you have code that is often repeated.

Keep your tests simple

Avoid using loops or conditions inside your tests. Tests should have a cyclomatic complexity of 1. If you find yourself writing something like this:

test('Test', () => {
...
  if (isDeleted) {
       // assert deleted state
  }
  else {
      // otherwise assert alive state
  }
...
})

that is a sign that you should have used two tests. By keeping tests simple you will minimize the risk of including bugs into them and they will be much easier to read and debug when needed. Also, prefer to have multiple simple tests, then having a single test that asserts multiple things.

Do not test implementation details

Always write tests from the perspective of the user. This will make your tests more robust, and they can survive refactors of the code they test. If you find yourself needing to change your tests often then you probably tested implementation details.

If you write tests for code that exposes a user interface, structure your test to follow steps that your user might take. This way you can change the internal structure of your code, but if the interface and behavior stay the same you won't have to change your test. This will give you confidence that your changes didn't break something unexpected.

Test naming

You should be able to figure out the aim of the test by simply reading its name. A good test name should also be understandable to business users. A good naming structure includes the application state before we executed our code, actions that were taken, and the expected state:

test('Logged in user clicks on refresh -> new posts are visible')

Tests are repeatable

For the same input/state tests should always fail or pass. If your tests sometimes fail, this is a sign that you have some randomness inside your code and will lose confidence in your tests. The usual suspect that may cause such behavior is using the current date in the code you test. You can extract code that provides this information in a utility that can be injected into your code so that you can be sure that your application state is consistent between test runs.

Also, every test needs to clean up after itself. Each testing framework has some way of running a cleanup code after test runs (for example afterEach in jest), so the state from one test doesn't leak into another. Every test should be a unit in itself. Avoid writing tests that depend on the order of execution. It is extremely hard to debug tests that pass in isolation but fail as part of a test suite.

Check that your tests are actually working

If you are using TDD in your process, you will have immediate validation of whether your tests are checking the code you are writing or not. But if you write tests after you have written your code it is easy to write a test that will always pass. In those cases, you should always make slight changes to pieces of code that you are testing (e.g. reverse a condition), just to make sure your tests are working.

Avoid magic numbers or strings

When asserting test results we often use magic numbers or strings. This makes it complicated later on when trying to decipher why we used those values. It is better to assign them to variables so that we can explicitly name them, especially if it happens to be that this value is the result of our setup.

expect(result).toBe(1); // magic numbers

const expectedUserPosts = 1; // now it is clear what 1 means
expect(result).toBe(expectedUserPosts );

Tests are code too

I have seen often that developers when writing tests, forget all coding principles. Tests are expected to evolve just as your codebase evolves. We must use good coding practices when writing tests, otherwise refactoring them would be a nightmare. Extract code pieces in the same test suite into helper functions so if you have to change something, you will have to change it in a single place. Also, try to use descriptive variable names and add comments to help developers that are debugging the test.

Integrate tests in your CI/CD process

Tests should be run after each change that is pushed into your main production code. If you use git, you should run tests after each pull request so that you are sure that the new code didn't break any old behavior. Tests should be fast so that you don't slow down the development process. If you have some tests that are slow (e.g. E2E tests), you can put them in a separate test suite, and run them once a day so you don't slow down your process but also have ample time to fix the potential issues before you publish your code to production. Also, make sure all your tests passed before pushing new code.

Create documentation

Consistency is key when working in larger teams. It is important to have some sort of dev documentation, where you outline all of the rules that the developers should follow while writing tests. This way it is easier to onboard new developers and teaches them best practices when dealing with tests. Also, try to include examples of different test cases that developers can use when writing a new test since we usually have few distinct test scenarios depending on the type of code we are testing.

Testing hero

Writing tests can often be very frustrating at the beginning. You won't be sure what to test or how to mock some application state so that you can test your code. It is good to have a person in your organization that you can lean on and that can guide you when writing your tests. They can educate their colleagues on the best testing practices, ensure that tests follow the same naming and structure, that we don't test implementation details. They can also be involved in pair programming sessions to give more inexperienced developers insight into the thought process when writing tests.

Conclusion

In this post, I highlighted some tips that I find useful when writing tests. I hope you find them useful and would like to hear in the comment section down below some of your own tips that you find useful when writing tests.

An in-depth guide to useState hook

Dino Kacavenda — Mon, 18 Jan 2021 16:04:27 +0000

In this article, I will draw attention to some problems and edge cases that may occur while using the useState hook. This hook stores a value that is used when rendering components. It is one of the most commonly used hooks, and most of the time you can use it with no problems and it will behave as expected. But there are some exceptions, which I will cover in this article.

The topics that I will address are:

When will setState cause a re-render?
React.memo and changing state
setState changes are not immediately visible
Batching
Lazy initialization
When to use setState with a callback?
Using useState to store element reference

When will setState cause a re-render?

If you are familiar with class components, you might think that the hook equivalent of this.setState always causes a re-render. The hook method uses the Object.is on every state change (call of setState method) and compares the previous value with the newer one. That being said, if we use the useState with primitive values (number, string, boolean, undefined, symbol) it will not cause a re-render if the value didn't change:

Object.is(2, 2); // true
Object.is("value", "value"); // true
Object.is(true, true); // true
Object.is(undefined, undefined); // true
Object.is(null, null); // true

If we use the useState with objects or functions, a re-render would happen only when the reference changes:

Object.is({}, {}); // false
Object.is([], []); // false
Object.is(() => console.log(""), () => console.log("")); // false
const foo = {a: 1};
const clone = foo;
Object.is(foo, clone); // true
Object.is(foo, {a: 1}); // false

This is one of the reasons why we should never directly mutate state because React will not detect the change and cause a re-render. It is also important when dealing with objects/arrays to not only set the new values but also to copy the previous ones (if you used React class components this behavior is different since React would have merged new and previous state values, so you would only need to set changes). So, if we have a complex state with nested objects:

// complex state with nested objects
const [complexState, setComplexState] = useState({
    foo: 'bar',
    bar: 'foo',
    errors: {
         foo: 'required',
         bar: 'required'
    }
})

and want to change the errors.foo value we would do it like this:

setComplexState({
    ...complexState,
    errors: {
         ...complexState.errors,   // we need to copy deeply nested object
        foo: 'new value'
    }
})

Object.is used to compare states when setState is called. Primitive values are compared by value, and the complex ones by reference

React.memo and changing state

React.memo will not prevent a re-render of the component where we use the useState hook. React.memo is strictly used to bailout of re-rendering child components when their parent re-renders. I intentionally didn't use the phrase: "when props change", since by default child components will re-render even if props stayed the same, and their parent rendered (only memoized components do a shallow comparison of props).

The mentioned behavior differentiates from its class component equivalent: shouldComponentUpdate, which is triggered when both state or props change, and can bail out of rendering even when the state changes.

React.memo doesn't prevent re-rendering when state changes when using useState

setState changes are not immediately visible

When we call setState, state change won’t be visible straight away. React will queue the update and sometimes even batch multiple updates so our components don't render too many times (more on that in the next section).

const [state, setState] = useState(0);

useEffect(() => {
    setState(1);
    console.log(state); // state is still 0
}, []);

State changes are visible in the next render

Batching

It is quite common that we use multiple useState hooks, and call their set methods inside the same callback/useEffect call. React will by default batch those updates togheter so that our component will render only once, and not for each setState call:

export default function Component() {
  const [state1, setState1] = useState(0);
  const [state2, setState2] = useState(0);

  useEffect(() => {
    console.log({ state1, state2 });
  });

  const onClick = () => {
    setState1(state1 + 1);
    setState2(state2 + 1);
  };

  return <button onClick={onClick}>Click Me</button>;
}

when we click on the button, in the next render, we will see updated state1 and state2. There will never be a situation in which state1 !== state2.

However, there are some cases in which React will not batch updates:

if we call setState methods inside an async function
if we call setState inside a setTimeout/setInterval

This is usually not a big performance issue, since React renders are pretty fast, but we could end up in an intermediate state that we didn't expect, and it could cause our application to stop working.

If we alter the previous example, into changing the state after a timeout:

export default function Component() {
  const [state1, setState1] = useState(0);
  const [state2, setState2] = useState(0);

  useEffect(() => {
    console.log({ state1, state2 });
  });

  const onClick = () => {
    // state is changed inside a setTimeout now
    setTimeout(() => {
      setState1(state1 + 1);
      setState2(state2 + 1);
    }, 0)
  };

  return <button onClick={onClick}>Click Me</button>;
}

By clicking on the set button, our component would render twice: the first render would update state1, and the second one would update state2.

There is an unstable API provided by React which can batch updates even inside async/setTimeout calls: React.unstable_batchedupdates. It is used internally by React when batching changes in event handlers or during a sync flow.

I personally prefer to use the useReducer hook when dealing with interconnected states. It allows me to write exact state changes (creating a state machine of sorts) with ease and helps me eliminate the possibility of rendering our component in an intermediate state. An example of this is a simple useFetch hook, that clearly defines all possible states:

function useFetch(initialState = {isLoading: true}) {
  // defined our state machine, so we are certain only these states
  // are possible and all connected states are updated in single render
  const reducer = (state, action) => {
    switch (action.type) {
        case 'request':
            return { isLoading: true };
        case 'response': {
            return { isLoading: false, data: action.data };
        }
        case 'error': {
            return { isLoading: false, error: action.error };
        }
        default:
            return state;
    }
  };

  const [fetchDataState, dispatch] = useReducer(reducer, initialState);

  const fetchData = async (fetchOptions, abortSignal) => {
    try {
        dispatch({ type: 'request' });
        const data = await fetcher.fetchData(fetchOptions, abortSignal);
        // this will set both loading and fetched data for next render
        dispatch({ type: 'response', data: data });
    } catch (e) {
        dispatch({ type: 'error', error: e });
    }
  };

  return { ...fetchDataState, fetchData };
}

The state changes will not be batched when using inside async or setTimeout/setInterval flow

Lazy initialization

When we want to initialize state with some potentially expensive operation, which we don't want triggering on every render (for example filtering of a big list), we can put a custom function when initializing useState. That function will only be called on the first render, and its results will be set as the initial value of the useState:

const [state, setState] = useState(() => {
     props.initialValue.filter(...) // expensive operation
})

You just need to be careful that this is only called on the first render. If I have props, for example, that are used to initialize state, I like to prefix the prop name with initial or default to signal other devs that this value will not be synced if it changes.

useState supports lazy initialization for expensive operations

When to use setState with a callback?

setState has two call signatures:

you can call it with a new value
you can call it with a callback that receives the current value as an argument and returns the new value

The callback signature is beneficial when calling setState inside a useCallback hook so that we don't break memoization.

If we have a simple component that uses useState and useCallback hooks with a memoized child component, and write it using the simple setState call signature:

const [state, setState] = useState(0);

const onValueChanged = useCallback(() => {
     setState(state + 1);
}, [state, setState]);

return <div>
     {state}
     <MemoizedChild onValueChanged={onValueChanged }  />
</div>

we will ruin the optimization of our MemoizedChild. Since onValueChanged will change on every state change, its reference will change as well, which will result in different props being sent to our child component (even if it doesn't use state in its props). This can be fixed easily by using the callback signature:

const [state, setState] = useState(0);

const onValueChanged = useCallback(() => {
     setState(prevState => prevState + 1); // change to callback signature
}, [setState]); // remove state from dependencies since callback will provide current value

return <div>
     {state}
     <MemoizedChild onValueChanged={onValueChanged }  />
</div>

This will work because the setState reference will be constant throughout the whole lifecycle of our component. With this adjustment, the MemoizedChild component will not render when the state changes.

Use the callback signature of setState when using with useCallback

Using useState to store element reference

When you need to reference a React element you can usually use the useRef hook. However, what if you want to do something with the element when it is first rendered (i.e., attach an event listener, calculate dimensions, ...) or if you want to use the reference as a dependency for useEffect/useCallback? In these cases useRef will not trigger a re-render of our component, so we would need to combine it with the useEffect. You could use useState to get the object reference, and it would force a re-render after the element is rendered, so you could access it:

export default function Component() {
  const [buttonRef, setButtonRef] = useState();

  useEffect(() => {
    console.log({ buttonRef });
  });

  return <button ref={setButtonRef}>Click Me</button>;
}

This way you would save the element reference in the state as soon as the element is rendered, and could safely use it without manually syncing it.

Conclusion

In this article, I covered some advanced useState cases. Hope you enjoyed it and found it useful :)

If you are interested in learning more about this topic, you can check these links:

Advanced TypeScript Tips & Tricks

Dino Kacavenda — Mon, 11 Jan 2021 09:43:07 +0000

In this article, I will show you some common issues that I have encountered while writing TypeScript applications and how to avoid them. This article is not meant to teach TypeScript, and presumes you have some experience with the language.

Topics covered:

Type assertions trap
Mapping and filtering values with correct types
Using exhaustive checks
Extending enums

Type assertions trap

TypeScript is all about type safety and trying to catch developer's mistakes at compile time, and not at runtime. TypeScript has two ways of assigning a value to a variable and giving it a type:

Type assertion -> override type that TypeScript has inferred
Type declaration -> assign type when declaring the variable

Imagine we have the following interface defined:

interface User {
    name: string;
    surname: string;
    address?: string;
}

and we define a new user object:

// type declaration
const user1: User = {
    name: "Adele",
    surname: "Vance"
};

// type assertion
const user2 = {
     name: "Christie",
     surname: "Cline"
} as User;

In both cases we would get IntelliSense and TypeScript warning us that we
have mistyped some property:

// type declaration
const user1: User = {
    namee: "Adele", // this will give a warning
    surname: "Vance"
};

// type assertion
const user2 = {
     namee: "Christie", // this will give a warning
     surname: "Cline"
} as User;

But what happens if we change address from optional to a required parameter? One would expect that TypeScript would give a warning in both cases?

Only Type Declaration will give a warning!

When using type assertion we tell TypeScript that we know better, and it should trust us. Type assertion will only fail if we mistype something, but it won't warn us if we forget some required properties.

If you use strictNull check option, you will even be able to assign null/undefined to a required property!

This is a common mistake when trying to type a result of map filtering:

const randomStrings = ['Bob', 'Alice', 'Vance'];
const mockNames = randomStrings.map(value => ({name: value, surname: value})); // type is {name: string; surname: string}[]

// but we want to strongly type it so we get intellisense, so we try like this
const typedMockNames = randomStrings.map(value => ({name: value, surname: value} as User)); // type is User[]

It will not warn us when we make the address required. The only type safe solution is using type declaration or generic parameter of map function:

const randomStrings = ['Bob', 'Alice', 'Vance'];

const typedMockNames = randomStrings.map(value => {
     const user: User = { name: value, surname: value };
     return user;
}) // type is User[]

const typedMockNamesGeneric = randomStrings.map<User>(value => ({name: value, surname: value})) // type is User[]

Always try to use type declarations, and if you have to use type assertions be sure you know the implications when changing type definitions.

Mapping and filtering values with correct types

When working with collections it is a common use case to map them to some objects, but also to filter some values out.

For example, we have a list of user-names and their age, and we want to filter out only users above a certain age and gather their user-names:

interface User {
    name: string;
    age: number;
}

const users: User[] = [{name: 'Adele', age: 32}, {name: 'Brian', age: 70}];

const filteredUsers = users.map(user => {
    if (user.age > 60) {
        return undefined;
    }

    return {name: user.name};
}).filter(Boolean);

Using filter(Boolean) is a common way to remove all values that don't satisfy our condition, but the problem is that the type of our filteredUsers variable will be: ({name: string} | undefined)[]. Also, since filter function always removes falsy values, we know for certain that it's type will never include undefined. We could try using type assertion to fix the problem, but we had already seen in the
previous example issues that may occur while using that approach.

A better solution is to define a custom type guard function that will filter out falsy values (like Boolean) but also provide us with type safety:

function isDefined<T>(value: T | undefined) value is T {
    return value !== undefined;
}

Now if we change the example to use our isDefined function, TypeScript will infer the correct type:

const filteredUsers = users.map(user => {
    if (user.age > 60) {
        return undefined;
    }

    return {name: user.name};
}).filter(isDefined); // type is now {name: string}[]

Using exhaustive checks

A great feature of TypeScript is discriminated unions. Which allow TypeScript to narrow down an object type using a literal field. This is a great way to set up some rules when creating complex systems. They allow TypeScript to warn developers in compile time of all the possible places where you are expected to implement when adding new functionality.

Let's imagine we have a simple calculator app that has a type for defining an operation and a function that will check if provided arguments are valid (real-world applications often have multiple functions that are scattered across multiple files):

interface Operation {
    type: 'add'; // our literal type used to create a discriminated union
    calculate: (args: number[]) => number;
}

function isOperationValid(operation: Operation, arguments: number[]) {
    switch(operation.type) {
        case "add":
            return true;
    }
}

We then decide that we want our calculator to support division so we change our Operation type to include it:

interface Operation {
    type: 'add' | 'division'; // expanded type to include the new operation
    calculate: (args: number[]) => number;
}

It would be great if TypeScript could warn us that we have functions that need implementing actions when dealing with the new operation type. Well since TypeScript is awesome, it can do this by using exhaustive checks.

They are extremely simple to use, we just need to add a default condition to our switch/case statements and we are good to go:

// helper function for doing exhaustive check
function exhaustiveCheck(value: never): never {
    throw new Error('Invalid type');
}

function logOperation(operation: Operation) {
    switch(operation.type) {
        case "add":
            logOperation(operation);
        default:
            exhaustiveCheck(operation.type); // we will get an error here that operation.type cannot be assigned to never
    }
}

Warning notice will disappear when we handle case for division in our logOperation function. Exhaustive check can also be used with if statements, just add it as the last line:

function logOperation(operation: Operation) {
    if (operation.type === 'add') {
        // do something
        return;
    }

    exhaustiveCheck(operation.type); // the same error as before
}

Extending enums

If you come from C# you know you can add the Description attribute to enums that you can use as display values to show to the user. TypeScript can do something similar using a feature called namespace merging.

You can add a simple getLabel function using the following code:

enum PrincipalType {
    User,
    Admin,
    Group
}

namespace PrincipalType {
    export function getLabel(p: PrincipalType) {
        switch(p) {
            case PrincipalType.Admin:
                return "Administrator";
            case PrincipalType.User:
                return "User";
            case PrincipalType.Group:
                return "Security Group";
        }
    }
}

PrincipalType.getLabel(PrincipalType.Admin); // "Administrator"

Conclusion

In this article, I showed you some TypeScript problems and how to solve them. TypeScript is an excellent tool, but like any tool, it is important that we properly wield it :). I hope that these examples helped you and that you were able to learn something from them. Till next time!