In this course, we'll start with the fundamentals of abstract syntax trees (ASTs) and learn the basic mental models. This general AST knowledge can be translated to almost any tool that works with ASTs.

## Why this course?

Understanding and using ASTs unlocks the ability to make sweeping changes in a safe and reliable way in any size codebase.

## Course topics

Throughout this course, we'll have converted source code into ASTs, traversed, mutated, and generated ASTs. With these concepts we'll then explore several practical applications including things like code audits (static analysis), code transformations (codemods), and linting.

### Module 1

We'll learn the fundamentals of abstract syntax trees. 

- What is an AST?
- How to explore an AST
- Examples of JavaScript tools that work with ASTs

### Module 2

We'll learn how to work with ASTs.

- How to turn code into an AST
- How to programmatically navigate any AST 
- How to leverage TypeScript to prevent runtime errors

### Module 3

We'll learn how to statically analyze, or "audit" code to understand the state of the codebase using abstract syntax trees.

- An introduction to an example codebase and refactor
- Understanding the state of the current codebase
- When to use an AST-based tool versus doing something manually

### Module 4

We'll learn how to transform, or "codemod" code from one state to another using abstract syntax trees.

- How to make changes to an AST
- How to change ASTs with [jscodeshift](https://github.com/facebook/jscodeshift)
- How to test a code transform

### Module 5

We'll learn how to write rules, or "lint" code using abstract syntax trees.

- How to create rules for code
- How to create custom rules with [ESLint](https://eslint.org)
- How to test a rule

In this course, you'll learn the fundamentals of abstract syntax trees, what they are, how they work, and dive into several practical use cases of abstract syntax trees to maintain a JavaScript codebase.

Practical Abstract Syntax Trees

---
title: How to Test Custom ESLint Linting Rules With AST
description: Testing custom ESLint linting rules to verify they work as expected
privateVideoUrl: "https://fullstack.wistia.com/medias/ga71wnpusa"
code: https://gitlab.com/fullstackio/books/newline-course-apps/spencer-miskoviak-practical-abstract-syntax-trees-app/-/tree/main/code/module_06/lesson_06.03/App/flash-cards?ref_type=heads
---

# Testing custom linting rules

Testing custom ESLint rules has similar benefits to testing a custom jscodeshift transform. First, taking a test-driven approach when creating custom rules can offer a faster feedback loop. The tests run significantly faster than trying to run them on an entire codebase. Second, if the rule is complex or shared across many different codebases, tests can help provide confidence that the rule is working as intended.

## Testing a rule

To get started, create a new file `no-button-element.test.js` alongside the rule in the `eslint-rules` directory, with an import for the rule and the `RuleTester` utility from ESLint.

```javascript { actualFilename=./protected/flash-cards/eslint-rules/no-button-element.test.js endLine=4 startLine=1 statedFilename=no-button-element.test.js url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_06/lesson_06.03/protected/flash-cards/eslint-rules/no-button-element.test.js }
// Import the custom rule definition.
const rule = require("./no-button-element");
// Import the utility provided by ESLint to test custom rules.
const { RuleTester } = require("eslint");
```

The rule tester uses the default ESLint configuration (not the one provided by Create React App) so any necessary configuration also needs to be passed to the `RuleTester` when initialized. By default, ESLint only expects ES5 syntax. In this case, only the [parser options](https://eslint.org/docs/user-guide/configuring/language-options#specifying-parser-options) need to be specified to enable JSX support (eg: `<button>`) otherwise the ESLint parser will throw an invalid syntax error.

```javascript { actualFilename=./protected/flash-cards/eslint-rules/no-button-element.test.js endLine=15 startLine=6 statedFilename=no-button-element.test.js url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_06/lesson_06.03/protected/flash-cards/eslint-rules/no-button-element.test.js#L6 }
// Initialize a new rule tester instance, with the default
// configuration to use for all test cases.
const ruleTester = new RuleTester({
  parserOptions: {
    ecmaFeatures: {
      // Enable support for JSX (eg: <button>)
      jsx: true,
    },
  },
});
```

Then, the test cases can be defined and run. The `RuleTester` has a [`run` method](https://eslint.org/docs/developer-guide/nodejs-api#ruletester) to execute tests. It expects three arguments: the rule name, the rule definition, and test cases.

Testing custom ESLint linting rules to verify they work as expected