Turn Every Issue into a Targeted Unit Test with Automated Scripts

Background

The author maintains the ICBU low‑code platform rendering engine, which powers over 160 applications and 600 pages, with more than 1,000 daily npm downloads. Although test coverage reached 95%, the team realized that high coverage alone does not guarantee bug‑free releases, especially for a core library where any change can cause unexpected failures.

Issue‑Driven Test Generation

To ensure that every change is covered, the team adopted an "issue = unit test" approach. Each user‑reported issue is created as an issue in a designated repository. A bot notifies the responsible developer via DingTalk, and after the fix, the bot informs the issue creator.

Every issue has a destined unit test.

Automation Scripts

A new npm script tnpm run create-issue was added to the package.json to generate a test scaffold and a demo for a given issue ID.

// package.json
"scripts": {
    "create-issue": "node ./script/issue_dev/createIssueTem.js"
}

// createIssueTem.js
/**
 * Quick issue‑based test creation example
 */
const path = require('path');
const execSync = require('child_process').execSync;
const args = process.argv.slice(2);
const issueID = args[0];
if (!issueID) {
  console.error('需要输入issue id才能运行');
  process.exit();
}
const demoTarget = path.resolve(__dirname, `../../demo/issue_${issueID}`);
const demoSrc = path.resolve(__dirname, '../template/demo/base.md');
const testTarget = path.resolve(__dirname, `../../test/issues-cov/${issueID}`);
const testSrc = path.resolve(__dirname, '../template/test/*');
const specTarget = path.resolve(__dirname, `../../test/issues-cov/${issueID}/app.spec.tsx`);
execSync(`mkdir ${demoTarget}`);
execSync(`cp ${demoSrc} ${demoTarget}/`);
execSync(`sed -i '' 's/issueID/${issueID}/g' ${demoTarget}/base.md`);
execSync(`mkdir ${testTarget}`);
execSync(`cp ${testSrc} ${testTarget}`);
execSync(`sed -i '' 's/issueID/${issueID}/g' ${specTarget}`);
console.log(`创建${issueID}成功`);

Running tnpm run create-issue 123456 creates a demo and a test file based on a shared template, allowing developers to view the demo in a browser or edit the test directly in VS Code.

Pre‑Build Cleanup

Before building, a script removes demo directories associated with issues when the build environment is set to cloud:

// prebuild – delete issue demos
const fs = require('fs');
const path = require('path');
const ENV = process.env.BUILD_ENV == 'cloud';
function removeDir(dir) {
  let files = fs.readdirSync(dir);
  for (let i = 0; i < files.length; i++) {
    let newPath = path.join(dir, files[i]);
    let stat = fs.statSync(newPath);
    if (stat.isDirectory()) {
      removeDir(newPath);
    } else {
      fs.unlinkSync(newPath);
    }
  }
  fs.rmdirSync(dir);
}
fs.readdir('./demo', (err, paths) => {
  if (err) console.log(err);
  paths.forEach(pathItem => {
    if (pathItem.includes('issue') && ENV) {
      removeDir(`./demo/${pathItem}`);
      console.log(`删除${pathItem}`);
    }
  });
});

Demo, Documentation, and Changelog Integration

The generated demo links back to the original GitLab issue, creating a traceable path: DingTalk → issue → npm changelog. The changelog marks which features are "cover by test" using the issue ID, e.g.:

# 1.24.0
1. 【FEAT】列表过滤提供类似表单的校验模式 #115827（cover by test）
2. 【FEAT】model内置属性应该不可枚举 #116193（cover by test）
3. 【FEAT】期望提供ref注解，方便平台侧做区分 #116364
4. 【Bug】watch 在正则的模式下，调用 silent validate 会导致 autoValidate 失效 #116242（cover by test）

This tight coupling ensures every unit test can be traced back to its originating issue and version.

Conclusion

After a year of practice, the framework has accumulated over 170 unit tests, including more than 60 issue‑specific atomic tests. While zero bugs cannot be guaranteed, the issue‑driven testing strategy dramatically reduces regression risk, making the library more reliable for downstream users. The best time to write tests is before a project starts, and if not then, now.