zoukankan      html  css  js  c++  java
  • [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.

     
  • 相关阅读:
    js禁止页面回退,刷新,右键代码
    asp.net网站中的Gridview循环判断数据是否被选中
    Gridview中同时选中并删除多个数据
    asp.net中在后台更换控件图片的代码
    关于gcd的8题
    flash AIR 通过BitmapData生成图片到android Camera相册
    flash AIR 通过BitmapData生成图片到本地
    C的随机数
    xcode svn设置事项
    拒绝session丢失 利用DIV层实现对模态窗口的模拟
  • 原文地址:https://www.cnblogs.com/Answer1215/p/9899484.html
Copyright © 2011-2022 走看看