[Testing] Static Analysis Testing JavaScript Applications

Posted Answer1215

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[Testing] Static Analysis Testing JavaScript Applications相关的知识,希望对你有一定的参考价值。

The static code analysis and linting tool ESLint is the de-facto standard for linting javascript projects. In this lesson we’ll see how to install, run, and configure it for your preferences.

 

Install:

npm i -D eslint

 

Run:

npx eslint src

 

Create: .eslintrc file

{
    "parserOptions": {
        "ecmaVersion": "2018"
    },
    "extends": [
        "eslint:recommended"
    ],
    "rules": {
        "no-console": "off"
    },
    "env": {
        "browser": true,
        "node": true,
        "es6": true,
        "jest": true
    }
}

 

 

The code formatting tool prettier can help you avoid a lot of useless time spent formatting code and arguing about code formatting with your co-workers. It can also help you catch subtle issues with your code that you may not notice otherwise. In this lesson we’ll learn how to install and run prettier.

Install:

npm i -D prettier

Run:

"format": "prettier --write "**/*.+(js|jsx|json|yml|yaml|css|less|scss|ts|tsx|md|graphql|mdx)""
npm run format

In VSCode: Settings.json

{
  "editor.formatOnSave": true
}

 

Prettier is a pretty opinionated tool, but it does allow for some customization. In this lesson we’ll check out the prettier playground and see what options we want to enable in our project’s .prettierrc file.

After adding in our custom configuration, we’ll create a .prettierignore file so that you can avoid formatting any files generated within the project such as node_modules or a build folder.

.prettierrc:

{
  "arrowParens": "avoid",
  "bracketSpacing": false,
  "insertPragma": false,
  "jsxBracketSameLine": true,
  "parser": "babylon",
  "printWidth": 80,
  "proseWrap": "always",
  "requirePragma": false,
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "all",
  "useTabs": false
}

.prettierignore:

node_modules
coverage
dist
build
.build
.vscode
package.json
package-lock.json
debug.log

 

 

Because prettier can automatically fix a lot of stylistic issues in our codebase, it’s not necessary to have eslint check for those and it can actually be kind of annoying if it does. So let’s see how we can use eslint-config-prettier to disable all rules that are made irrelevant thanks to prettier.

Install:

npm i -D eslint-config-prettier

.eslintrc:

{
    "parserOptions": {
        "ecmaVersion": "2018"
    },
    "extends": [
        "eslint:recommended",
        "eslint-config-prettier"
    ],
    "rules": {
        "no-console": "off"
    },
    "env": {
        "browser": true,
        "node": true,
        "es6": true,
        "jest": true
    }
}

 

 

You can’t force everyone on your project to use the prettier integration for their editor, so let’s add a validation script to verify that prettier has been run on all project files.

Fortunately for us, Prettier accepts a --list-different flag that you can use that will throw an error when code is not up to the standard of your project.

  "scripts": {
    "test": "node --require ./setup-global.js src/index.js",
    "lint": "eslint src",
    "format": "npm run prettier -- --write",
    "prettier": "prettier "**/*.+(js|jsx|json|yml|yaml|css|less|scss|ts|tsx|md|graphql|mdx)"",
    "validate": "npm run lint && npm run prettier -- --list-different"
  },

We can run:

npm run validate

to check whether there is any files which is not formatted. 

If it is, then will throw error, we can run:

npm run format

to format the code.

 

ESLint can check for a lot of things, but it’s not a great tool for checking the types of variables that flow through your application. For this you’ll need a type-checking tool like Flow or TypeScript. Let’s see how we can configure our project to work with Flow.

Install:

npm i -D flow-bin

Add script:

"flow": "flow",

Run:

npm run flow

For the first time, we run ‘npm run flow‘ will tell us to run:

npm run flow init

it create a .flowconfig file.

 

Create a exmaple js file to pratice flow:

//@flow

function add(a: number, b: number): number {
    return a + b
}
type User = {
    name: {
        first: string,
        middle: string,
        last: string,
    },
}
function getFullName(user: User): string {
  const {
    name: {first, middle, last},
  } = user
  return [first, middle, last].filter(Boolean).join(‘‘)
}
add(1,2)

getFullName({name: {first: ‘Joe‘, middle: ‘Bud‘, last: ‘Matthews‘}})

Run:

npm run flow

 

We won‘t see any error for this, if everything is correct type checking.

We have a ‘validate‘ script setup previously:

"validate": "npm run lint && npm run prettier -- --list-different"

we can also add "flow" into it:

"validate": "npm run lint && npm run prettier -- --list-different && npm run flow"

In order to make ‘validate‘ script works, we still need to install ‘babel-eslint‘ for eslint to understand flow syntax:

Install:

npm i -D babel-eslint

.eslintrc:

{
    "parser": "babel-eslint",
    "parserOptions": {
        "ecmaVersion": "2018"
    },
    "extends": [
        "eslint:recommended",
        "eslint-config-prettier"
    ],
    "rules": {
        "no-console": "off"
    },
    "env": {
        "browser": true,
        "node": true,
        "es6": true,
        "jest": true
    }
}

Then run:

npm run validate

it will checks eslint, prettier and flow.

 

We have a few checks we’ll run in continuous integration when someone opens a pull request, but it’d be even better if we could run some of those checks before they even commit their code so they can fix it right away rather than waiting for CI to run. Let’s use husky’s precommit script to run our validation.

Install:

npm i -D husky

Hook with ‘precommit‘ with valdiation:

"precommit": "npm run validate"

If you don‘t want this precommit hook and commit you changes anyway you can do:

git commit -m "bad stuff" --no-verify

 

 

Rather than failing when a developer has failed to format their files or run linting on all the files in the project on every commit, it would be even better to just automatically format the files on commit and only check the relevant files with eslint. Let’s use lint-staged to run scripts on the files that are going to be committed as part of our precommit hook.

Install:

npm i -D lint-staged

package.json:

"precommit": "lint-staged && npm run flow"

.lintstagedrc:

{
  "linters": {
    "*.js": [
      "eslint"
    ],
    "**/*.+(js|jsx|json|yml|yaml|css|less|scss|ts|tsx|md|graphql|mdx)": [
      "prettier --write",
      "git add"
    ]
  }
}

Now when you do commit, it will automatcilly format all the code and readded to git and commit it.

 

Full code here.

 

以上是关于[Testing] Static Analysis Testing JavaScript Applications的主要内容,如果未能解决你的问题,请参考以下文章

Static Program Analysis - Chapter 3Type Analysis

Pure C static coding analysis tools

静态时序分析(static timing analysis)

WWDC: Thread Sanitizer and Static Analysis

静态时序分析(static timing analysis) --- 时序路径

《Static Timing Analysis for Nanometer Designs》汇总传送门