/api_tdd_jest

Primary LanguageJavaScript

Starting on tests

This repo is a step-by-step tutorial on how to start a project using TDD and set up our developer pipeline to ensure consistency and test coverage

Git aliases

  • Create folder and start git in it

  • git config --local --edit - show git config file for this directory in default editor (vim), you can change the file here if you're comfortable with this interface

  • git config --local core.editor "code" - change the default editor to Visual Studio Code

  • run again git config --local --edit - now the configuration file will be opened in VSC

  • Create aliases for our git flow:

    • 'c' - add files to stage and commit;
    • 'l' - show logs with custom format;
    • 's' - show status from our staged files in short way
(...)
[alias]
    c = !git add . && git commit -m
    l = !git log --pretty='%C(blue)%h %C(white)%s %C(cyan)%an - %C(green)%cr'
    s = !git status -s

Commit linter hook

We will use a "linter" to avoid making commits out of pattern. All our commits need to have a type definition:

  • feat - adding new feature to our commit
  • chore - change build process, add libraries or change configurations on our pipeline
  • test - includes changes or new tests on our code
  • refactor - changes on code that don't change the behavior

The patern will be <type>: <subject> the first word on subject has to be an imperative verb in lowercase

  • examples:
    • chore: add express framework
    • feat: create login route for user authentication
    • refactor: move createUser method to new file

check on Convetional Commits to more details about commit pattern

To ensure we always make commits using the same pattern we will install git-commit-msg-linter as a developer dependency in our project. This lib creates a pre-commit hook that checks if the commit subject is following that pattern

npm i -D git-commit-msg-linter

Don't forget to commit this chore to ensure a nice git commit stack.

Husky Pre Commiter

Just like Commit Msg Linter, we'll use another lib to create our own git hooks, this will enable us to check if our code is following the patterns we decided to use and if it passes every test before we commit new code.

$ npx husky-init

This command will change our package.json including Husky as devDependency, adding the new script 'prepare'. This will run husky every time we start working with this project and we first execute npm i to install all dependencies.

You will notice a new folder called .husky and inside, a file called pre-commit. Here we will configure what we want Husky to execute before every commit.

After that we need to download and install Husky.

$ npm i

To check if it's working, change the last line on .husky/pre-commit file

    (...)
    echo "Husky first running"

Now we need to commit this new chore, and you can see our message "Husky first running" on terminal

👍🏼 Really cool!!!

Standard JS

Standard is a style guide, linter and formatter to our js files, you can check the standard rules in StandardJS Rules

Using Standard is simple, first we need to install it as a Dev Dependency

$ npm i -D standard

We can already make some tests following standard rules. Create a js file called standardTest.js in your project root folder.

Include in this file:

function hello() {
  return { a: 1 };
}

Notice our file is out of pattern with a lot of spaces

run

$ nxp standard standardTest.js

Your terminal will list all the problems Standard notices in your code

if you run

$ npx standard standardTest.js --fix

The fix option will correct all the problems Standard can correct but the fact our function is created but never used will need to be fixed manually.

We want in every commit we run that Standard checks the style guide and fix what is fixable, so now we need to change our pre-commit file on Husky to run Standard

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx standard --fix

💡 You can change your test file again, removing style patterns, including extra spaces and, after that, commit this chore to see Standard in action.

Lint Staged

In a real project we'll have a huge amount of files. Imagine that in every commit we make, it automatically run test scripts for every single file, even the files we don't change. It's unecessary and we can solve that using a lib that will run scripts only on our staged files (in other words all the files that will be changed in our commit)

For that we need to install lint-staged as a Dev Dependency

$ npm i -D lint-staged

After that create a new file in our project root folder called .lintstagedrc.json

With the following content:

{
  "*.js": ["echo lint-staged running", "npx standard --fix", "git add"]
}

In this .json we configure lint-staged to ensure every .js file runs the following commands in the array, first just a message saying that lint staged is running, then it will check and fix our js following Standard rules and if changes were made we will add the files again.

💡 To check if it worked, you can change your sum.js file and run

$ npx lint-staged

Now we need to tell Husky to execute lint-staged. We will change the file .husky/pre-commit again.

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

After that you can change sum.js again and execute a new commit for this chore and check in your terminal lint-staged running 😊

Tech

Libs we are using for this tutorial