summaryrefslogtreecommitdiff
path: root/cli/tools/test/reporters
AgeCommit message (Collapse)Author
2024-08-20feat(cli/tools): add a subcommand `--hide-stacktraces` for test (#24095)Hajime-san
2024-05-22feat(cli): Add slow test warning (#23874)Matt Mastracci
By default, uses a 60 second timeout, backing off 2x each time (can be overridden using the hidden `DENO_SLOW_TEST_TIMEOUT` which we implement only really for spec testing. ``` Deno.test(async function test() { await new Promise(r => setTimeout(r, 130_000)); }); ``` ``` $ target/debug/deno test /tmp/test_slow.ts Check file:///tmp/test_slow.ts running 1 test from ../../../../../../tmp/test_slow.ts test ...'test' is running very slowly (1m0s) 'test' is running very slowly (2m0s) ok (2m10s) ok | 1 passed | 0 failed (2m10s) ``` --------- Signed-off-by: Matt Mastracci <matthew@mastracci.com> Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-05-08chore: enable clippy::print_stdout and clippy::print_stderr (#23732)David Sherret
1. Generally we should prefer to use the `log` crate. 2. I very often accidentally commit `eprintln`s. When we should use `println` or `eprintln`, it's not too bad to be a bit more verbose and ignore the lint rule.
2024-03-26fix(cli): output more detailed information for steps when using JUnit ↵Yusuke Tanaka
reporter (#22797) This patch gets JUnit reporter to output more detailed information for test steps (subtests). ## Issue with previous implementation In the previous implementation, the test hierarchy was represented using several XML tags like the following: - `<testsuites>` corresponds to the entire test (one execution of `deno test` has exactly one `<testsuites>` tag) - `<testsuite>` corresponds to one file, such as `main_test.ts` - `<testcase>` corresponds to one `Deno.test(...)` - `<property>` corresponds to one `t.step(...)` This structure describes the test layers but one problem is that `<property>` tag is used for any use cases so some tools that can ingest a JUnit XML file might not be able to interpret `<property>` as subtests. ## How other tools address it Some of the testing frameworks in the ecosystem address this issue by fitting subtests into the `<testcase>` layer. For instance, take a look at the following Go test file: ```go package main_test import "testing" func TestMain(t *testing.T) { t.Run("child 1", func(t *testing.T) { // OK }) t.Run("child 2", func(t *testing.T) { // Error t.Fatal("error") }) } ``` Running [gotestsum], we can get the output like this: ```xml <?xml version="1.0" encoding="UTF-8"?> <testsuites tests="3" failures="2" errors="0" time="1.013694"> <testsuite tests="3" failures="2" time="0.510000" name="example/gosumtest" timestamp="2024-03-11T12:26:39+09:00"> <properties> <property name="go.version" value="go1.22.1 darwin/arm64"></property> </properties> <testcase classname="example/gosumtest" name="TestMain/child_2" time="0.000000"> <failure message="Failed" type="">=== RUN TestMain/child_2&#xA; main_test.go:12: error&#xA;--- FAIL: TestMain/child_2 (0.00s)&#xA;</failure> </testcase> <testcase classname="example/gosumtest" name="TestMain" time="0.000000"> <failure message="Failed" type="">=== RUN TestMain&#xA;--- FAIL: TestMain (0.00s)&#xA;</failure> </testcase> <testcase classname="example/gosumtest" name="TestMain/child_1" time="0.000000"></testcase> </testsuite> </testsuites> ``` This output shows that nested test cases are squashed into the `<testcase>` layer by treating them as the same layer as their parent, `TestMain`. We can still distinguish nested ones by their `name` attributes that look like `TestMain/<subtest_name>`. As described in #22795, [vitest] solves the issue in the same way as [gotestsum]. One downside of this would be that one test failure that happens in a nested test case will end up being counted multiple times, because not only the subtest but also its wrapping container(s) are considered to be failures. In fact, in the [gotestsum] output above, `TestMain/child_2` failed (which is totally expected) while its parent, `TestMain`, was also counted as failure. As https://github.com/denoland/deno/pull/20273#discussion_r1307558757 pointed out, there is a test runner that offers flexibility to prevent this, but I personally don't think the "duplicate failure count" issue is a big deal. ## How to fix the issue in this patch This patch fixes the issue with the same approach as [gotestsum] and [vitest]. More specifically, nested test cases are put into the `<testcase>` level and their names are now represented as squashed test names concatenated by `>` (e.g. `parent 2 > child 1 > grandchild 1`). This change also allows us to put a detailed error message as `<failure>` tag within the `<testcase>` tag, which should be handled nicely by third-party tools supporting JUnit XML. ## Extra fix Also, file paths embedded into XML outputs are changed from absolute path to relative path, which is helpful when running the test suites in several different environments like CI. Resolves #22795 [gotestsum]: https://github.com/gotestyourself/gotestsum [vitest]: https://vitest.dev/ --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-02-28fix(cli): ensure that pre- and post-test output is flushed at the ↵Matt Mastracci
appropriate times (#22611) Some `deno_std` tests were failing to print output that was resolved after the last test finished. In addition, output printed before tests began would sometimes appear above the "running X tests ..." line, and sometimes below it depending on timing. We now guarantee that all output is flushed before and after tests run, making the output consistent. Pre-test and post-test output are captured in `------ pre-test output ------` and `------ post-test output ------` blocks to differentiate them from the regular output blocks. Here's an example of a test (that is much noisier than normal, but an example of what the output will look like): ``` Check ./load_unload.ts ------- pre-test output ------- load ----- output end ----- running 1 test from ./load_unload.ts test ... ------- output ------- test ----- output end ----- test ... ok ([WILDCARD]) ------- post-test output ------- unload ----- output end ----- ```
2024-02-09fix: upgrade to deno_ast 0.33 (#22341)David Sherret
* Uses diagnostics from deno_ast * Real fix for https://github.com/denoland/deno/pull/22310 * Moves `deno lint --json` code here * Upgrades swc Closes #22117 Closes #22109 Closes #21927 Closes #20993
2024-02-05refactor(cli): Add TestFailureDescription (#22267)Matt Mastracci
Extract zero-risk changes from #22226
2024-01-27Revert "refactor(cli): use new sanitizer for resources (#22125)" (#22153)Bartek Iwańczuk
2024-01-26refactor(cli): use new sanitizer for resources (#22125)Matt Mastracci
Step 1 of the Rustification of sanitizers, which unblocks the faster timers. This replaces the resource sanitizer with a Rust one, using the new APIs in deno_core.
2024-01-01chore: update copyright to 2024 (#21753)David Sherret
2023-11-01fix(test): --junit-path should handle when the dir doesn't exist (#21044)David Sherret
Closes https://github.com/denoland/deno/issues/21022
2023-10-05feat(jupyter): support Deno.test() (#20778)Nayeem Rahman
2023-10-05refactor(test): support custom writer in PrettyTestReporter (#20783)Nayeem Rahman
2023-09-06fix: don't show filtered test suites as running (#20385)Marvin Hagemeister
2023-08-26feat(cli/tools): add TAP test reporter (#14390) (#20073)Valentin Anger
This PR adds a test reporter for the [Test Anything Protocol](https://testanything.org). It makes the following implementation decisions: - No TODO pragma, as there is no such marker in `Deno.test` - SKIP pragma for `ignore`d tests - Test steps are treated as TAP14 subtests - Support for this in consumers seems spotty - Some consumers will incorrectly interpret these markers, resulting in unexpected output - Considering the lack of support, and to avoid implementation complexity, subtests are at most one level deep (all test steps are in the same subtest) - To accommodate consumers that use comments to indicate test-suites (unspecced) - The test module path is output as a comment - This is disabled for `--parallel` testing - Failure diagnostics are output as JSON, which is also valid YAML - The structure is not specified, so the format roughly follows the spec example: ``` --- message: "Failed with error 'hostname peebles.example.com not found'" severity: fail found: hostname: 'peebles.example.com' address: ~ wanted: hostname: 'peebles.example.com' address: '85.193.201.85' at: file: test/dns-resolve.c line: 142 ... ```
2023-08-17fix(test): JUnit reporter includes file, line and column attributes (#20174)Alexander Michaud
Closes #20156
2023-08-02feat(cli): Add dot test reporter (#19804)Bartek Iwańczuk
This commit adds a "dot" reporter to "deno test" subcommand, that can be activated using "--dot" flag. It provides a concise output using: - "." for passing test - "," for ignored test - "!" for failing test User output is silenced and not printed to the console. In non-TTY environments each result is printed on a separate line.
2023-07-27refactor(cli/test): move reporters to a separate directory (#19957)Bartek Iwańczuk
Just a small cleanup that will make #19804 easier.