Refactor testing setup about deno_lint HOT 4 CLOSED

@lucacasonato looks good - I suggested skipping line number because in most cases tests can be written on single line:

assert_lint_ok::<RequireYield>("function foo() {}");
assert_lint_ok::<RequireYield>("function* bar() { yield "bar"; }");

// source code, expected diagnostic code, expected column
assert_lint_err::<RequireYield>("function* bar() { return "bar"; }", "requireYield", 10);

Maybe it would make sense to have a helper that asserts there is single diagnostics returned and separate helper that returns array of diagnostics (user gives number of expected diagnostics)?

assert_lint_err_n::<RequireYield>(3, "function* bar() { return "bar"; }");

from deno_lint.

This is what I have right now:

fn ban_ts_ignore() {
  let diagnostics = assert_lint_err::<BanTsIgnore>(
    r#"
// @ts-ignore
function foo() {
// pass
}

function bar() {
// @ts-ignore
const a = "bar";
}
  "#,
  );
  assert_has_diagnostic(&diagnostics, "banTsIgnore", 2, 0);
  assert_has_diagnostic(&diagnostics, "banTsIgnore", 8, 2);
}

Does that seem reasonable? I don't think we should be ignoring line number because it is actually important in many cases. I agree the file name can be ignored. Also should we also check the error message? I personally think the error code is enough.

EDIT: we also need some way to check that there are no diagnostics left over after the asserts. So maybe pop off the diagnostics that we checked from the diagnostics vec and then assert at the end that the vec is empty?

from deno_lint.

One more thought: asserting valid code can probably be done by passing vector of test cases

assert_lint_ok::<RequireYield>(vec![
  "function foo() {}",
  "function* bar() { yield "bar"; }",
]);

from deno_lint.

Cleanly done by @lucacasonato in #72

from deno_lint.