1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-30 16:40:57 -05:00
Commit graph

12 commits

Author SHA1 Message Date
Asher Gomez
5f44148e83
chore: update to std@2024.07.19 (#24715) 2024-07-25 15:30:28 +10:00
Asher Gomez
f248050cb4
chore: use @std prefix for internal module specifiers (#24543)
This change aims to replace all relative import specifiers targeted at
`tests/util/std` with mapped ones (using a `deno.json` file). Towards
updating the `std` git submodule.
2024-07-25 10:26:54 +10:00
David Sherret
da52058a94
chore: migrate bench, publish, and more itests to spec tests (#23584) 2024-04-29 10:08:27 -04:00
Yusuke Tanaka
64e8c36805
fix(cli): output more detailed information for steps when using JUnit 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-03-26 00:08:46 +09:00
Matt Mastracci
736b91edd0
perf(cli): use new deno_core timers (#22569)
Improves #19100 

Fixes #20356

Replaces #20428



Changes made in deno_core to support this:

 - [x] Errors must be handled in setTimeout callbacks
 - [x] Microtask ordering is not-quite-right
 - [x] Timer cancellation must be checked right before dispatch
 - [x] Timer sanitizer
 - [x] Move high-res timer to deno_core
 - [x] Timers need opcall tracing
2024-03-01 11:15:18 -07:00
Matt Mastracci
b6e44f91ad
fix(cli): ensure that pre- and post-test output is flushed at the 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-28 22:12:21 +00:00
Matt Mastracci
a3f982c1d5
chore(cli): rename --trace-ops to --trace-leaks (#22598)
As we add tracing to more types of runtime activity, `--trace-ops` is
less useful of a name. `--trace-leaks` better reflects that this feature
traces both ops and timers, and will eventually trace resource opening
as well.

This keeps `--trace-ops` as an alias for `--trace-leaks`, but prints a
warning to the console suggesting migration to `--trace-leaks`.

One test continues to use `--trace-ops` to test the deprecation warning.

---------

Signed-off-by: Matt Mastracci <matthew@mastracci.com>
2024-02-28 09:12:43 -07:00
Matt Mastracci
67a4231bb6
refactor(cli): move op sanitizer to Rust (#22413)
The format of the sanitizers will change a little bit:

- If multiple async ops leak and traces are on, we repeat the async op
header once per stack trace.
- All leaks are aggregated under a "Leaks detected:" banner as the new
timers are eventually going to be added, and these are neither ops nor
resources.
 - `1 async op` is now `An async op`
- If ops and resources leak, we show both (rather than op leaks masking
resources)

Follow-on to https://github.com/denoland/deno/pull/22226
2024-02-16 21:22:12 +00:00
Matt Mastracci
c92717a1a4
chore(cli): pre-factor the sanitizer tests (#22436)
Moving tests around so that we can make #22413 smaller
2024-02-16 10:49:42 -07:00
Matt Mastracci
e23fc6d88c
chore: deno_core bump (#22407)
- Adding `None` flag for warmup script.
 - Modify opcall trace interface to match new Rust implementation
2024-02-13 19:44:37 -07:00
Asher Gomez
6be389ce29
chore: move test_util/std to tests/util/std (#22402)
Note: tests are not the only part of the codebase that uses `std`. Other
parts, like `tools/`, do too. So, it could be argued that this is a
little misleading. Either way, I'm doing this as discussed with
@mmastrac.
2024-02-13 09:22:49 -07:00
Matt Mastracci
f5e46c9bf2
chore: move cli/tests/ -> tests/ (#22369)
This looks like a massive PR, but it's only a move from cli/tests ->
tests, and updates of relative paths for files.

This is the first step towards aggregate all of the integration test
files under tests/, which will lead to a set of integration tests that
can run without the CLI binary being built.

While we could leave these tests under `cli`, it would require us to
keep a more complex directory structure for the various test runners. In
addition, we have a lot of complexity to ignore various test files in
the `cli` project itself (cargo publish exclusion rules, autotests =
false, etc).

And finally, the `tests/` folder will eventually house the `test_ffi`,
`test_napi` and other testing code, reducing the size of the root repo
directory.

For easier review, the extremely large and noisy "move" is in the first
commit (with no changes -- just a move), while the remainder of the
changes to actual files is in the second commit.
2024-02-10 20:22:13 +00:00