DEV Community: Sammy Abukmeil

JavaScript Testing Basics

Sammy Abukmeil — Tue, 14 May 2024 14:38:11 +0000

What is Testing
Benifits of Testing
Types of Tests
- Unit Tests
- Integration Tests
- End-to-End Tests

Getting Started
- Local development setup
- Writing our first test
- Using it() instead of test()
- Detecting bugs

Best Practices
- How to structure tests
- Avoid hardcoding values
- Keep tests simple
- Test multiple scenarios
- Testing is an iterative process

More Examples
- Test if an empty array is passed
- Test if it throws an error when no argument is passed
- Test for falsy values with .not
- Test if a specific error message is thrown
- Test if the result is a specific type

What is testing

Testing is all about writing code ("tests") which automates the process of checking whether your application is working as intended.

You can run the tests:

After you make changes (to ensure your changes didn't break anything else)
During your CI/CD pipeline to ensure you're not pushing bugs to production

Benifits of testing

Testing helps with:

Confidence when refactoring (you'll be sure that your changes haven't broken anything)
Less bugs in production
Less manual testing
Forces you to write better code (code that's easy to test)

Types of tests

There are a few different categories of tests which test different things, and you should aim to add each of these to your app:

Unit tests

Test the smallest building blocks ("units") of your app (e.g. a function, a class, or a component in React).

Integration tests

Test multiple units to ensure they work well together.

End-to-End tests

Test an entire flow/feature of your app (e.g. a user uploading an image).

Generally, you want:

A lot of unit tests
Less integration tests
A small amount of end-to-end tests

As shown in this testing pyramid

Getting Started

Local development setup

We need a tool to achieve the following:

Test Runner - Runs the tests and shows the results
Assertion Library - The test themselves, what to check etc

A popular tool for both of these features is Jest, however, Jest can be slow when executing tests, and requires extra setup to use ECMAScript modules (i.e. import x from "y" syntax)

A modern alternative is Vitest (prounounced "vee-test") which works in the same way as Jest, is fast and supports ECMAScript modules out of the box.

Let's start by making a directory

mkdir testing
cd testing

Create a package.json file

npm init -y

Install vitest as a dev dependency

npm i vitest --save-dev

Create a index.js file with the following contents

export function add(numbers) {
  let sum = 0;

  for (const number of numbers) {
    sum += number;
  }

  return sum;
}

Note: The functions that we'll be testing in this article are intentionally simple, in order to keep the tests simple

This is the first function we'll test

Create a index.test.js file with the following code

import { expect, test } from "vitest";
import { add } from "./index";

test("should sum all numbers in an array", () => {
  const result = add([1, 2, 3]);

  expect(result).toBe(6);
});

The test in the file name is important, Vitest looks for files with test in and executes the tests within them.

In your package.json file add a script to run vitest

{
  "scripts": {
    "test": "vitest"
  },
  "devDependencies": {
    "vitest": "^1.6.0"
  }
}

Now run the test script

npm test

You should see the following output

Writing our first test

Now we have our test runner & assertion library setup, let's revisit our test

test("should sum all numbers in an array", () => {
  const result = add([1, 2, 3]);

  expect(result).toBe(6);
});

The test() method sets up a new test and takes two arguments

A string describing what we're testing
A callback function to execute when the test executes

Inside the callback function, we simply execute the function we want to test and store the result in a variable: const result = add([1, 2, 3])

The expect() method takes one argument:

The value that the assertion library will check

The toBe() method takes one argument:

Checks if the value that was given to expect() is a particular value

In this case, the sum of [1, 2, 3] should result in 6, hence expect(result).toBe(6)

Using it() instead of test()

We can make the name of our test easier to read by using the it() method, which does the same thing as test()

import { expect, it } from "vitest";
import { add } from "./index";

it("should sum all numbers in an array", () => {
  const result = add([1, 2, 3]);

  expect(result).toBe(6);
});

As you can see, our code reads better "It should..." rather than "Test should..."

Detecting bugs

If another developer on your team makes a change to the original function e.g. changing let sum = 0 to let sum

export function add(numbers) {
  let sum;

  for (const number of numbers) {
    sum += number;
  }

  return sum;
}

When the tests run, an issue is detected and the test fails

The output tells you the following:

Which test(s) failed
What value the test was expecting
What value the test actaully recieved

index.test.js
   × should sum all numbers in an array

AssertionError: expected NaN to be 6

- Expected
+ Received

- 6
+ NaN

This is happening since the variable sum is now undefined , and adding a number to undefined results in NaN

This will prompt the developer to review their change, and therefore the presence of this unit test has prevented a bug from being committed 🎉

Best Practices

How to structure tests

A common pattern for structuring a unit test is the Triple A Pattern

Arrange - Define the values that we're going to use
Act - Execute the function we want to test
Assert - Check if the expected outcome happened

Currently out test is only "Acting" and "Asserting"

it("should sum all numbers in an array", () => {
  // Act
  const result = add([1, 2, 3]);

  // Assert
  expect(result).toBe(6);
});

Let's add the "Arrange" step to make our test clearer

it("should sum all numbers in an array", () => {
  // Arrange
  const numbers = [1, 2, 3];  

  // Act
  const result = add(numbers);

  // Assert
  expect(result).toBe(6);
});

Avoid hardcoding values

Our test is currently hardcoding the expected value

expect(result).toBe(6);

But what if a developer changes the numbers in the arrange step without updating the expected value

it("should sum all numbers in an array", () => {
  const numbers = [1, 2];  

  const result = add(numbers);

  expect(result).toBe(6);
});

Now our test will fail, and we might start debugging the function rather than the test by mistake.

We can dynamically calulate the expected value to make our test more reliable:

it("should sum all numbers in an array", () => {
  const numbers = [1, 2];

  const result = add(numbers);

  const expectedResult = numbers.reduce((acc, curr) => acc + curr, 0);
  expect(result).toBe(expectedResult);
});

Here we're using the reduce() array method to loop over the values in the numbers array and add them up.

This isn't necessary, however, it does arguably make your test clearer, in terms of how the final value is calculated.

Keep tests simple

When arranging your tests, keep the input values as simple as possible

it("should sum all numbers in an array", () => { 
  // Good
  const numbers = [1, 2];

  // Bad
  const numbers = [1, 2, 3, 4, 5, 6];

  // ...
});

Regardless if we provide 2 or 6 input values, the test will establish whether "should sum all numbers in an array" is working or not.

To keep our test simple, we should go for the simplist set of inputs. This will help your colleagues understand the test quickly.

If, for example, you want to test if the functions works with a lot of input values (or negative numbers) you could write a sepatate test for that scenario.

Test multiple scenarios

Currently we're only testing one scenario, the "ideal scenario" so to speak (i.e. the function recieved an array of numbers).

What about the following scenarios:

A value that can't be converted to a number (e.g. invalid) is passed to the function
Strings which contain numbers (e.g. "1") are passed

We can write tests for these scenarios!

Test for failed conversions

Let's start off by writing a test for scenario 1 above:

it("should return NaN if a least one invalid number is passed", () => {
  const inputs = ["invalid", 1];

  const result = add(inputs);

  expect(result).toBeNaN();
});

Here we're using the toBeNaN() provided by Vitest - there are lots of other methods available for other scenarios we might expect (see the right hand sidebar here)

If we run this test, it fails with the message

AssertionError: expected '0invalid1' to be NaN

This is because JavaScript encounters a string in the numbers array and converts everything to a string and concatinates them.

We can update our function force each value in the array to be a number like so:

export function add(numbers) {
  let sum = 0;

  for (const number of numbers) {
    sum += Number(number);
  }

  return sum;
}

Now our test passes since Number("invalid") results in NaN

In fact, both our tests are passing

Which confirms the last change didn't break the function.

Test for string to number conversions

Let's also add a test for the scenario 2 (when strings that can be converted to numbers are passed)

it("should return a correct sum even if an array of numeric string values is passed", () => {
  const numbers = ["1", "2"];

  const result = add(numbers);

  const expectedResult = numbers.reduce(
    (acc, curr) => Number(acc) + Number(curr),
    0
  );
  expect(result).toBe(expectedResult);
});

Take note of a couple of statements here:

We're providing strings with numbers in ["1", "2"]
In the .reduce(), we're converting the acc variable (the accumulator in the reduce loop) and curr variable (the current value in the reduce loop) to numbers

Important: Make sure not to introduce bugs in your tests, you can console.log(expectedResult) and console.log(typeof expectedResult) in your test to ensure the dynamically calculated expected value is correct

Note: console logs will be shown by Vitest in the terminal output

When we run our tests, we see that the new test, as well as all previous tests, are passing!

This is due to the refactor we made earlier in our add() function sum += Number(number).

Now, going forward, your and your colleagues can run these tests any time and be 100% certain that this function works in those scenarios, even after making changes to it.

Testing is an iterative process

At a certain point you'll ask yourself "Should I write any more tests for this unit?"

The answer is "it depends!"

Have you written tests for the main scenarios?
Do you tests cover good and bad scenarios?

As time goes on, you may continue working on the unit that you're testing, and therefore you should revisit the tests.

More Examples

You may not feel the need to add these tests, it's up to you, but these are some examples of scenarios you could test for it it's important to you and your team.

Test if an empty array is passed

Let's add a test for a scenario where a developer calls this function and passes an empty array, in which case, it shouldn't crash but instead simply return 0

it("should return 0 if an empty array is passed", () => {
  const numbers = [];

  const results = add(numbers);

  expect(results).toBe(0);
});

When we run our tests, we find that our function already behaves that way - great!

At least now it's clear to everyone how the function behaves in this scenario.

You can consider your tests as a form of documentation for your code - a developer can look at the tests and see how it behaves without even trying it out.

Test if it throws an error when no argument is passed

There are a couple of approaches to check if an error is thrown in a test:

Wrap it in a try...catch statement
Wrap the function call in a function, and use .toThrow()

The try...catch approach

it("should throw an error if no value is passed", () => {
  try {
    add();
  } catch (error) {
    expect(error).toBeDefined();
  }
});

Here we're using .toBeDefined() to check if the error object is defined

The .toThrow() approach

it("should throw an error if no value is passed", () => {
  const resultFn = () => {
    add();
  };

  expect(resultFn).toThrow();
});

Here we're wrapping the function call add() in an anonymous function, then passing a reference to the function to expect() and chaining on .toThrow()

With this approach, the expect() method will execute the wrapping function resultFn() and check whether it throws

Test for falsy values with .not

For any of the example above, we can chain the .not property to check if a statement evaluates to a falsy value e.g.

expect(resultFn).not.toThrow();

expect(results).not.toBe(0);

Test if a specific error message is thrown

Let's write a test to see if, when passing individual numbers as arguments instead of an array, a specific error message is thrown

it("should throw an error if multiple arguments are passed instead of an array", () => {
  const num1 = 1;
  const num2 = 2;

  const resultFn = () => {
    add(num1, num2);
  };

  expect(resultFn).toThrow(/is not iterable/);
});

Here we're passing a regular expression to .toThrow()

If you hover your mouse over the the method, you'll see what you can pass in

It could be

A string that we expect the error.message to be
A regular expression (i.e. a pattern to check for part of a message)
A class which the error might be an instance of

In our example above, we provided the following regular expression /is not iterable/ (i.e. the error.message must include those three words somewhere in the string)

Since we're using a for...of loop in our function which expects a value that can be looped over (i.e. an "iterable"), passing in a couple of numbers add(num1, num2) will throw that error message.

Test if the result is a specific type

Consider this function

export function convertToNumber(value) {
  return Number(value);
}

Note: The functions that we'll be testing in this article are intentionally simple, in order to keep the tests simple

We can write a test which checks if the function returns a value of a specfic via .toBeTypeOf()

it("converts a string with a number inside to a number", () => {
  const input = "1";

  const result = convertToNumber(input);

  expect(result).toBeTypeOf("number");
});

TypeScript Basics

Sammy Abukmeil — Thu, 11 Jan 2024 12:18:56 +0000

What is TypeScript
Setup a Local Environment
- Create a folder to practice TypeScript
- Setup a package.json file
- Install TypeScript as a dev dependancy

Vanilla TypeScript
- Typing Variables
- Typing Arrays
- Tuples
- Typing Objects
- Enums
- Type Aliases
- Interfaces
- Union Types
- Typing Functions
- Typing Classes
- Generics

TypeScript with React
- Creating a Vite app
- File Extension
- Typing Props
- Typing State

TypeScript with Express
- Setting up an Express TypeScript app
- Using Types in Express

What is TypeScript

TypeScript extends JavaScript by adding "types" to the language
It provides a command line interface (cli) which we can run to compile our TypeScript to JavaScript via the cli command tsc
This helps spot bugs during development (i.e. when we're building our apps) and therefore prevent bugs from happening during "runtime" (when a user is using our apps)

For example, here's some TypeScript:

let firstName: string = "Sammy";

The : string is TypeScript syntax which ensures that this variable will only ever contain a value of type string

If another developer attempts to assign a value to this variable of type number, TypeScript will throw an error in VS Code and won't compile via the tsc CLI

Setup a Local Environment

This section guides you through how to install and compile TypeScript code.

Create a folder to practice TypeScript

On your desktop create a typescript directory:

Open it in VS Code
Open a terminal

Setup a `package.json` file

npm init -y

Install TypeScript as a dev dependency

We use TypeScript during development (not to actually run the app), so we'll add the --save-dev flag to indicate that it's a dependency for development

npm install typescript --save-dev

We should now be able to run the cli

npx tsc

Which should output something like Version 5.3.3

Create a `tsconfig.json` file

We can control how the TypeScript compiler behaves via a JSON file, let's create it

npx tsc --init

This will generate a tsconfig.json file with some default settings

Let's add a setting to tell the TypeScript compiler where to find our TypeScript files and where to send our compiled JavaScript files

{
  "include": ["src"],
  "compilerOptions": {
    "outDir": "./build",
    ...
  }
}

Now create an src/ directory and inside of it create a index.ts

Add

let firstName: string = "Sammy";

inside the index.ts and run

npx tsc

You should now see a build directory with an index.js file inside.

Let's run

npx tsc --watch

Which will watch for changes in the TypesScript file and automatically transpile it to index.js

Vanilla TypeScript

Here are a few of the core features of TypeScript.

For a more detailed breakdown, take a look at the TypeScript Documentation.

Typing Variables

When creating variables, we can either provide an explicit type assignment:

let firstName: string = "Sammy";

In the code above, we're creating a variable and explicity telling TypeScript (via : string) that it must be a string.

TS Playground - Variables

There will be links to TS Playground for each section in this article going forward

It compiles TypeScript to JavaScript and shows the compiled code on the right

Click "Run" to execute the JavaScript and see any console logs

This makes your code easier to read/understand, and is more explicit.

You can also create a variable without a type and TypeScript will infer (i.e. guess) the type, based on the value:

let surname = "Abukmeil";

This is called an implicit type assignment.

You can hover over a variable in VS Code to check what type TypeScript inferred:

If you try to assign a value with the wrong type to a typed variable, TypeScript will highlight an error in VS Code (squiggly red line) and the TypeScript compiler will throw an error:

Type 'number' is not assignable to type 'string'

TS Playground - Incorrect Type Error

In TS Playground, you'll see the errors in two places:

In the panel on the left by hovering over the red squiggly line

In the panel on the right by switching to the "Errors" tab

This happens with both explicity typed variables and implicity typed variables.

Typing Arrays

When creating arrays, we can add a type like so

const games: string[] = ["Space Invaders", "Pac Man"];

The : string[] above says "this array can only contain strings"

TS Playground - Arrays

If we try to do the following

games.push(4);

We get the following error

Argument of type 'number' is not assignable to parameter of type 'string'

Tuples

A tuple is an array with a specific length & specific types for each index

let inventoryItem: [number, string, number] = [
  1, 
  "Gaming Monitor", 
  100
];

The : [number, string, number] above says "This array must have 3 items with the following types"

TS Playground - Tuples

So if we were to re-assign this variable, this is allowed:

inventoryItem = [2, "Microwave", 40];

Whereas this isn't (since the last element in the array should be a number):

inventoryItem = [2, "Toaster", "35"];

We get the following error Type 'string' is not assignable to type 'number'

When creating tuples, you can also give a name to each array item for clarity

let inventoryItem: [id: number, name: string, price: number] = [
  1,
  "Gaming Monitor",
  100,
];

Typing Objects

When creating objects, we can add a type like so

const game: { name: string; releaseYear: number } = {
  name: "Resident Evil",
  releaseYear: 1996,
};

where : { name: string; releaseYear: number } specifies the name and type for each property

TS Playground Example - Typing an object

Enums

An enum is a group of constants (i.e. variables that should never change).

For example

enum Directions {
  North,
  East,
  South,
  West
}

In the code above, we've defined some directions that we'll use in our app.

let currentDirection = Directions.North;

TS Playground Example - Enum

In the code above, we're creating a variable and setting it equal to one of our enum values.

If we console.log() this variable, we'll get 0

console.log(currentDirection); // 0

So each value in our enum is given a number starting from 0.

Now that variable can only ever be assigned a value from this enum.

If we try to set the variable to some other value

currentDirection = "Something Incorrect";

We'll get the following error Type '"Something Incorrect"' is not assignable to type 'Directions'

We can also change the numbers that the enum values are linked to

enum StatusCodes {
  Success = 200,
  NotFound = 404,
  ServerError = 500,
}

const currentStatus = StatusCodes.NotFound;

console.log(currentStatus); // 404

Or change the numbers that the enum values are linked to to be strings instead

enum Direction {
  Up = "UP",
  Down = "DOWN",
  Left = "LEFT",
  Right = "RIGHT",
}

const currentDirection = Direction.Up;

console.log(currentDirection); // UP

Type Aliases

We can define a Type Alias which makes types reusable and gives them a name.

type GameReleaseYear = number;

const pacmanYear: GameReleaseYear = 1980;
const spaceInvadersYear: GameReleaseYear = 1978;

TS Playground Example - Type Alias

In the code above, we created a Type Alias called GameReleaseYear which is a number.

This Type Alias is used for multiple variables.

We can define a Type Alias for any type, including objects:

type Game = {
  title: string;
  year: number;
};

const game: Game = {
  title: "Pac Man",
  year: 1980
}

TS Playground Example - Type Alias for an object

Interfaces

An interface is similar to a type alias, however, you can only use them for objects

interface Game {
  title: string;
  year: number;
}

const game: Game = {
  title: "Pac Man",
  year: 1980,
};

TS Playground Example - Interface

Interfaces have an additional feature compared to Type Aliases, that they can extend other interfaces:

interface Game {
  title: string;
  year: number;
}

interface IndieGame extends Game {
  developer: string
}

const indieGame: IndieGame = {
  title: "Stardew Valley",
  year: 2016,
  developer: "ConcernedApe"
};

Union Types

A union type allows a value to be more than one type

function displayId(id: number | string) {
  console.log(`ID is: ${id}`);
}

displayId(5);
displayId("ff72ce73-322d-4eb2-8029-c739d30c3ef5");

TS Playground Example - Union Type

In the code above, the id property could either be a string or a number

Typing Functions

We can specify what the return value type will be:

function getUserId(): number {
  return 5;
}

The : number above says "this function will return a value of type number"

We can add types for each of the parameters:

function sum(x: number, y: number): number {
  return x + y;
}

TS Playground Example - Typing Functions

In the code above, we've added types for the parameters and the return type via : number

We can use a type alias to define the function types separately:

type Multiply = (x: number, y: number) => number; 

const multiply: Multiply = (x, y) => {
  return x * y;
}

Typing Classes

When creating classes, we can add types for the properties and the methods

class Car {
  engineType: string;

  constructor(engineType: string) {
    this.engineType = engineType;
  }

  getEngineType(): string {
    return this.engineType;
  }
} 

const car = new Car("Six cylinders");

In the code above, we specify that the class has a property called engineType which is a string, and that the getEngineType() method returns a string

We can also use private and public keywords to specify if certain properties / methods are accessible outside of the class

class Car {
  private engineType: string;

  constructor(engineType: string) {
    this.engineType = engineType;
  }

  public getEngineType(): string {
    return this.engineType;
  }
}

const car = new Car("Six cylinders");
console.log(car.getEngineType());
console.log(car.engineType); // Error

In the code above, the engineType property is set private and therefore only accessible within the class, whereas the getEngineType() method is public and can be accessed outside of the class.

Instead of typing private engineType: string; outside of the constructor and engineType: string which is repetitive, we can combine both into the constructor:

class Car {
  public constructor(private engineType: string) {
    this.engineType = engineType;
  }

  public getEngineType(): string {
    return this.engineType;
  }
}

const car = new Car("Six cylinders");

TS Playground Example - Typing Classes

In the above code private engineType: string defines a property and constructs it.

Generics

Generic Functions

Generics allow your typed functions to accept any type

function getValue<Type>(value: Type): Type {
  return value;
}

In the code above, we define a generic function which can receive a parameter of any type, and return a value of any type.

const num = getValue<number>(10);

In the code above, we're using the generic function, giving a type of number

const str = getValue<string>("Hello");

TS Playground Example - Generic Function

In the code above, we're using the same generic function, giving a type of string

Here's another example

function reverse<Type>(array: Type[]): Type[] {
  return array.reverse();
}

const reversedNumbers = reverse<number>([1, 2, 3]);
const reversedStrings = reverse<string>(["Hello", "Bye"]);

TS Playground Example - Generic Function Example 2

In the code above, the parameter array is typed as Type[] i.e. an array of whichever type was declared. The return value is also typed as Type[] i.e. it will return an array of the declared type

Generic Type Aliases

When creating a type alias (See section "Type Aliases" above for a refresher), we can make it generic

type Person<Type> = {
  name: string;
  age: number;
  job: Type;
};

In the code above, we've defined a generic type, where the job property could be any type

const personOne: Person<boolean> = {
  name: "Jane",
  age: 21,
  job: false,
};

In the code above, we're using our generic type alias and specifying that the job property will be a boolean

const personTwo: Person<string> = {
  name: "John",
  age: 35,
  job: "Doctor",
};

TS Playground Example - Generic Type Alias

In the code above, we've used the same generic type alias, this time job will be a string

TypeScript With React

Here are a few way of using TypeScript in React

For a more detailed breakdown, take a look at the React Documentation.

Creating a Vite app

From this tutorial, we'll use Vite.

We can create a new Vite app with TypeScript by running the following command

npm create vite@latest

Choose the following options:

Select a framework -> React
Select a variant -> TypeScript

Note: Another common approach is to use Next JS

File Extension

Ensure your file extensions are .tsx (it wont work with .js or .jsx)

Typing Props

Let's start with an example:

// App.tsx
function App() {
  const handleTodo = (text: string) => {
    console.log(text);
  }

  return (
    <>
      <NewTodo handleTodo={handleTodo} />
    </>
  );
}

// NewTodo.tsx
interface Props {
  handleTodo: (text: string) => void;
}

function NewTodo({ handleTodo }: Props) {
  return (
    <>
      <button onClick={() => handleTodo("Hello")}>Click</button>
    </>
  );
}

Here we've used an interface to define a type for the props object.

In this case, there's only one key value pair:

Key: handleTodo - the name of the prop
Value: (text: string) => void - This prop is a function, so this type describes the function parameters and return type (void means the function doesn't return anything)

Typing State

Let's start with an example:

interface Todo {
  id: string;
  text: string;
}

function App() {
  const [todos, setTodos] = useState<Todo[]>([]);

  return (
    <>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id}>{todo.text}</li>
        ))}
      </ul>
      <button
        onClick={() => setTodos([...todos, { id: uuid(), text: "Hello" }])}
      >
        Add todo
      </button>
    </>
  );
}

Here we've used an interface to define a type for the state variable.

Todo[] means this state variable will contain an array of Todo type objects

useState() can be used as a Generic Function (as explained here) hence the following syntax useState<Todo[]>([])

TypeScript With Express

Here are a few way of using TypeScript in Express

Setting up an Express TypeScript app

Create an express app as usual:

npm init -y

npm i express

Install TypeScript as a dev dependancy, as well as some declaration packages for node and express

npm i -D typescript @types/express @types/node

These declaration packages (e.g. @types/express) can be found in the DefinitelyTyped GitHub Repo, which is a large collection of TypeScript type definitions.

For example, here are the type definitions for Express JS: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/express

Running npm i -D @types/express brings these into your node_modules/ directory and makes them usable in your application.

Create a tsconfig.json file

npx tsc --init

and ensure you set a directory for your compiled JS files to be sent to

{
  "compilerOptions": {
    ...
    "outDir": "./dist"
    ...
  }
}

This is how we'll run our app:

In development -> we want node to run our .ts files
In production -> we want node to run our comipled .js

Since node can't run .ts files natively, we need to install a library for executing TypeScript via node called ts-node

npm i -D ts-node

And to watch for file changes in development, we'll use nodemon

npm i -D nodemon

And setup some scripts to run our app

{
  "scripts": {
    "build": "npx tsc",
    "start": "node dist/index.js",
    "dev": "nodemon src/index.ts"
  }
}

Using Types in Express

Create a src directory and a index.ts file inside it with the following:

import express, { Express, Request, Response } from "express";

const app: Express = express();

app.get("/", (req: Request, res: Response) => {
  res.send("Express + TypeScript Server");
});

app.listen(3000, () => {
  console.log("Server is running on port 3000");
});

Here we're importing types for:

Express -> Type for the return value from express()
Request -> Type for the req parameter
Response -> Type for the res parameter

These are imported from the express package, which will search from them in @types/express

Productivity Tips

Sammy Abukmeil — Fri, 17 Nov 2023 15:46:31 +0000

Keyboard shortcuts in this post:

Switch between apps
Change multiple lines of code

Switch between apps

Keybinding:

Mac - CMD + TAB
Windows - ALT + TAB

To switch between open apps:

Hold CMD / ALT
Press TAB as many times until you get to the app you want to switch to
Release CMD

The two most recent apps will always be first in the list

Once you've got the two apps you want to switch between at the start:

Quickly CMD + TAB and let go

Change multiple lines of code