swellaby/vscode-rust-test-adapter

Rust Test Explorer extension for VS Code

Rust VS Code Test Explorer

Rust Test Explorer for VS Code that enables viewing and running your Rust tests from the VS Code Sidebar.

---

Functional, but still in an early Beta/Preview !!!!
Bugs are inevitable 😁

---

See the Test Explorer UI Extension for additional information.

Current Features

Detected unit tests will be viewable and runnable from the Test Explorer window as long as there is a Cargo.toml file in the root of the directory. It should also work with Cargo Workspaces, as well as packages that have both bin and lib targets.

The tree will reflect the package -> target -> module -> ... hierarchical structure. However, the tree will flatten the package level if there's only a single package, and/or at the target level if a package only has a single target containing unit tests.

We've got some sample projects in our samples repo for various scenarios.

Roadmap

The initial focus is the core functionality of viewing and running first unit tests.

Afterwards we're tentatively planning to make the individual test results available in the tree (i.e. when you click on failed test case node in the tree, test output will be viewable in VS Code Output Window). Next, we want to support discovering and running integration tests and documentation tests.

More info can be found in the GitHub Project

Other Projects

Here's some of our other Rust-related projects you may want to check out!

• rusty-hook - A git hook utility for your Rust projects
• VS Code Rust Extension Pack - A minimalist extension pack for Rust development in VS Code

License

MIT - see license details here

vscode-rust-test-adapter's Issues

Detect tests in tests/ folder

Hi,

Thanks for the nice extension.

I tried to use the "workspace" model where several members each have a Cargo.toml file.

Only the tests inside #[cfg(test)] modules are detected.
When putting tests in a tests/ folder in any member, they are properly picked by a cargo test, but not by the extension.

Support Integration Tests

Setup Release Pipeline

toolchain-file in workspace not being picked up

Originally posted by @JRAndreassen in #50 (comment)

Hi,
Thanks for getting back to me...

I have a project like:

+libs
 | -cargo.toml
 | + subprojA
 |     -  cargo.toml
 | + SubProjB
 |     -  cargo.toml
 |     -  toolchain

The libs\cargo.toml is a workspace:

[workspace]
members = [
     "subprojA"
    ,"subprojB"
]

exclude = [
    "subprojC",
]

---

subprojB has a "toolchain" file, which specifies that it should use the "nightly"

When the too issues the "cargo" command, it sets cwd to the parent "libs"..
Which does not pick up the "toolchain" file in the sub directory...

When I call cargo from subprojB directory or when I delete the workspace cargo, it compiles correctly.
So, my suspicion is that you would have to add the sub-project directory to the cwd
before issuing the command.

Thanks
JR

Originally posted by @JRAndreassen in #50 (comment)

Not finding tests folder

project/tests/* - not found in Test Explorer

project/src/tests/* - found in Test Explorer.

I believe that the official location for tests is the same level as src, not under src...

Python and Rust tests in the same vscode don't play well together

This could be very unfair to place this issue here, but I'm going to start here. Maybe it's a python issue, maybe it's an issue with the framework that's not handling things nicely and not the adapter. But I'm guessing that python and some other language does work ok based on usage stats and it's something we are doing that's annoying the others.

Sometimes we see multiple sets of tests, sometimes we see no rust tests. The tests also fail to start when clicked so it's really unhappy.

I'm not sure where we start with diagnosing this one but any tips will be greatly appreciated. It all works fine on a rust only project.

Capture test failure details

Capture the output of failed tests make it available on each test node in the explorer

Add prettier for code formatting

Ensure multiple test harnesses can be supported

We've (understandably) been focused exclusively on libtest so far, and there's still plenty of work to be done there. It would be good though to ensure we don't get locked into libtest as the only harness that can be supported and/or that we don't need another big refactor down the line to support additional harnesses

Support Documentation Tests

Dependency Dashboard

This issue provides visibility into Renovate updates and their statuses. Learn more

Other Branches

These updates are pending. To force PRs open, click the checkbox below.

• chore(deps): update dependency nth-check to 2.0.1 [security]
• chore(deps): update dependency path-parse to 1.0.7 [security]
• chore(deps): update dependency semver-regex to 3.1.3 [security]

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency eslint to v8

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency husky to v7

---

• Check this box to trigger a request for Renovate to run again on this repository

Support output from libtest-mimic

I'm using libtest_mimic to autogenerate a set of tests with same supported flags as regular cargo test harness.

Unfortunately, it seems that Rust Test Explorer doesn't detect those tests in the project. I'm not sure how it performs test enumeration - does it parse source files looking for #[test]? does it run something like cargo test -- --list? - but in case it's the latter, it is supported by libtest-mimic too and should, in theory, be possible to incorporate into the Rust Test Explorer.

E.g. this is the output I'm seeing when running cargo test -- --list on my project:

     Running target\debug\deps\spec-af280007c0fc00ca.exe
tests\testsuite\address.wast:3:2: test
tests\testsuite\address.wast:223:2: test
tests\testsuite\address.wast:514:2: test
tests\testsuite\address.wast:564:2: test
tests\testsuite\align.wast:3:2: test
tests\testsuite\align.wast:4:2: test
tests\testsuite\align.wast:5:2: test
tests\testsuite\align.wast:6:2: test
tests\testsuite\align.wast:7:2: test
tests\testsuite\align.wast:8:2: test
tests\testsuite\align.wast:9:2: test
tests\testsuite\align.wast:10:2: test
tests\testsuite\align.wast:11:2: test
tests\testsuite\align.wast:12:2: test
tests\testsuite\align.wast:13:2: test
tests\testsuite\align.wast:14:2: test
tests\testsuite\align.wast:15:2: test
tests\testsuite\align.wast:16:2: test
tests\testsuite\align.wast:17:2: test
tests\testsuite\align.wast:18:2: test
tests\testsuite\align.wast:19:2: test
tests\testsuite\align.wast:20:2: test
tests\testsuite\align.wast:21:2: test
tests\testsuite\align.wast:22:2: test
tests\testsuite\align.wast:23:2: test
tests\testsuite\align.wast:24:2: test
tests\testsuite\align.wast:25:2: test
tests\testsuite\align.wast:305:2: test
tests\testsuite\align.wast:309:2: test
tests\testsuite\align.wast:313:2: test
tests\testsuite\align.wast:317:2: test
tests\testsuite\align.wast:321:2: test
tests\testsuite\align.wast:325:2: test
tests\testsuite\align.wast:329:2: test
tests\testsuite\align.wast:333:2: test
tests\testsuite\align.wast:337:2: test
tests\testsuite\align.wast:341:2: test
tests\testsuite\align.wast:345:2: test
tests\testsuite\align.wast:349:2: test
tests\testsuite\align.wast:353:2: test
tests\testsuite\align.wast:357:2: test
tests\testsuite\align.wast:362:2: test
tests\testsuite\align.wast:366:2: test
tests\testsuite\align.wast:370:2: test
tests\testsuite\align.wast:374:2: test
tests\testsuite\align.wast:378:2: test
tests\testsuite\align.wast:382:2: test
tests\testsuite\align.wast:386:2: test
tests\testsuite\align.wast:390:2: test
tests\testsuite\align.wast:394:2: test
tests\testsuite\align.wast:398:2: test
tests\testsuite\align.wast:402:2: test
tests\testsuite\align.wast:406:2: test
tests\testsuite\align.wast:410:2: test
tests\testsuite\align.wast:414:2: test
tests\testsuite\align.wast:419:2: test
tests\testsuite\align.wast:423:2: test
tests\testsuite\align.wast:427:2: test
tests\testsuite\align.wast:431:2: test
tests\testsuite\align.wast:435:2: test
tests\testsuite\align.wast:439:2: test
tests\testsuite\align.wast:443:2: test
tests\testsuite\align.wast:447:2: test
tests\testsuite\align.wast:451:2: test
tests\testsuite\align.wast:458:2: test
tests\testsuite\align.wast:854:2: test
tests\testsuite\binary-leb128.wast:2:2: test
tests\testsuite\binary-leb128.wast:7:2: test
tests\testsuite\binary-leb128.wast:12:2: test
tests\testsuite\binary-leb128.wast:18:2: test
...

support features

Tests are not shown if they are behind a #[cfg(feature = "my_feature)]", this extension should support forwarding features to all cargo commands. i.e cargo test --features "a b c" -- --list

One thing to note is that you can not use --features in cargo workspaces

Root test suite not running when root only contains test cases.

Expected Behavior

When pressing the test button to run all tests suites and or test cases within the test explorer, the test explorer will iterate through the test suites and cases and process each one.

Actual Behavior

When pressing the test button with only test cases in the root, the explorer attempts to extract test suites 'root' and only be returned a list of test caseids. Attempting to get the ITestSuiteNode for a given id returns undefined resulting in the "node.isStructuralNode" check failing.

reference: extractPackageTestSuitesFromNodes

Steps to Reproduce the Problem

1. Create a simple cargo package with no dependencies and just package metadata.
2. Create a simple test case in main.rs
3. Attempt to run test case through explorer (run all tests button)

Specifications

• Version: 0.5.0
• Platform: Windows + wsl
• Subsystem: rustc 1.34.2 (6c2484dc3 2019-05-13), cargo 1.34.0 (6789d8a0a 2019-04-01)

Notes

• I don't have the time at the moment but I can look into writing the validation and checks for test cases within the root if you are busy.

Add json format parser

Add a parser to handle the json test results format

Add linkage to test function in code

Update the test tree structure to include a link to the corresponding test function in code

Add config option to specify toolchain

I'll often use rustup override to explicitly set the toolchain to use in a project directory (particularly for projects like rustfmt and clippy that often need a specific nightly version), but the cargo commands we're invoking in a newly spawned process for test discovery/execution don't seem to be picking that up.

I suspect that adding a rust-toolchain file would work, though I don't think we should fail to work without one. Let's add a config option to allow explicitly specifying toolchain

Code Cleanup

The current implementation was done quickly and messily as I forgot you cannot publish private extensions for VS Code to the Marketplace 😄

Need to refactor the codebase to make it cleaner and more manageable going forward

Setup PR Builds

Support for procedural macro crate

Now if I try to run test in a procedural macro crate I get a "not supported target type" error message in output console log.

My guess is that procedural macro crate are close to lib crate and I don't see real difference from tests point of view.

Navigate to test code on double click

Navigating to a test code after double clicking on it is very expected intuitive behavior present in most test explorers.

Fail pipeline on missing test results

Not sure yet what happened but the pipeline apparently is silently passing when the code coverage results file is missing 🤔

Seems the upgrade to the latest version of nyc #60 may have broken coverage again, and if so that should be fixed as part of this

Support cargo-xbuild

Rust supports custom test frameworks (example). Enable test discovery and runner for the cross compiler used in such cases (cargo xbuild / cargo xrun here )

Add cancel support

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (@swellaby)

Investigate using `--quiet` mode on test load

Add Unit Tests

Add Autorun test on save

It is unclear if autorun is supported or not by this extension, it's not mentioned but it appears in some parts of the sources. I never used autorun before in VSCode, so I may be mistaken on how it works. My guess is that the tests marked as autorun should run on file save. I don't expect much autodetection magic to know which tests to run depending on the file saved, so it would be okay if all tests marked were run on save.

My current layout looks like this:

src/
├── linked4
│   ├── mod.rs
│   └── test.rs
├── linked5
│   ├── mod.rs
│   └── test.rs
└── main.rs

So the tests are in a separate file from the module. I've tried to save the test file or the mod file. Nothing happens. I can't find any option in any extension to enable this. My guess the support should be provided in this extension but I might be wrong.

For the time being I added Alt-S as a keybinding to run all the tests, so I can do Ctrl-S ; Alt-S; to trigger a save, then test.

Add Configuration Options

Should allow the user to configure options like the root node names, whether to flatten tree hierarchy levels, etc.

Package on Open VSX Registry is invalid

Edit - Maintainer note - the root cause of the behavior identified in this issue has been sourced back to the current versions of the extension on the Open VSX registry (not managed by our team) being an invalid packaging. See #94 (comment) for more info on workarounds

---

---

I can't see my tests populated in Vscode

example

fn parse_pair<T: FromStr>(s: &str, separator: char) -> Option<(T, T)> {
    match s.find(separator) {
        None => None,
        Some(index) => match (T::from_str(&s[..index]), T::from_str(&s[index + 1..])) {
            (Ok(l), Ok(r)) => Some((l, r)),
            _ => None,
        },
    }
}

#[cfg(test)]
#[test]
fn test_parse_pair() {
    assert_eq!(parse_pair::<i32>("", ','), None);
    assert_eq!(parse_pair::<i32>("10,", ','), None);
    assert_eq!(parse_pair::<i32>(",10", ','), None);
    assert_eq!(parse_pair::<i32>("10,20", ','), Some((10, 20)));
    assert_eq!(parse_pair::<i32>("10,20xy", ','), None);
    assert_eq!(parse_pair::<f64>("0.5x", 'x'), None);
    assert_eq!(parse_pair::<f64>("0.5x1.5", 'x'), Some((0.5, 1.5)));
    // faulty input panics
    // assert_eq!(parse_pair::<f64>("0.5x1.5x10", 'x'), Some((0.5, 1.5)));
}

Can you please help?

Idempotence and system test in rustfmt failing

I haven't had a chance to dig into this one yet, but noticed that the idempotence test could not be executed from the Test Explorer while I was working on rustfmt

https://github.com/rust-lang/rustfmt/blob/master/src/test/mod.rs#L296

Add lint PR job

Error while debugging test: Error: Method not implemented.

Not sure it is a bug or not, all test cases of the project could be found in vscode test explorer, but could not be lanuched.

vscode version: 1.37.0
os: win10
rust-toolchain: stable msvc

Incorrect additional tests being executed when triggering run for suite

Currently, libtest supports filtering tests by either exact test spec matches (via --exact) or the default mode which is a "contains".

https://github.com/rust-lang/libtest/blob/dbf328db62eacebe1aa719fa806c729bafa319b3/libtest/lib.rs#L1378-L1396

When a user triggers a test run from a suite node in the test adapter view, we currently invoke cargo test with the associated args to run all the test cases under that suite tree since libtest only supports a single arg value for the test spec.

For example if the test mod name (and associated suite label in the tree) is foo, running the foo suite issues a command something like:

cargo test -p mypacakge --lib -- foo::

We do not individually invoke cargo test for each individual test case. We experimented with that approach early on, but found that launching a cargo command for each individual test case was exceptionally resource intensive to the point of making VS Code/the machine unusable.

The challenge with the current approach is that due to libtests filtering approach, any tests that contain that value anywhere in the full test path will be executed.

As an example, if the test listing for a workspace is like this:

test foo::test_one
test foo::test_two
test bar::foo::test_baz
test other::test_add

Triggering a run for the foo suite/node would result in the first three of those tests being executed which is undesired/unexpected (this happens because the bar::foo::test_baz test does contain foo::).

Long term/strategically, the best way to address this would be upstream in libtest to either have it support some additional filtering options (like startsWith or supporting Regex). However, we'll still need a tactical interim workaround because even if such a libtest addition would be accepted, it'd be a long time before the solution could be developed and then released and then aged enough for the Rust Test Adapter to assume that patched version of libtest exists/is available for the majority of users.

Some potential work around options I can think of:

1. Keep the test execution piece in the adapter as-is, but modify the parsing/updating of the test nodes in the tree to filter out the unexpected tests (bar::foo::test_baz from the example above). This is rather wasteful but probably the easiest to implement.
2. Enhance the tree construction process with a new phase to identitfy the various --skip args that would be needed for each suite node in the tree to ensure the correct cargo test command can be constructed. This would probably be the "right" solution as far as continuing to let libtest handle most of the work while ensuring that we only trigger the exection of the correct tests. However, it'd definitely add some load to the initial tree construction process as each test suite node would have to be visited after the initial tree was built.
3. Revist the test execution strategy and reconsider executing test cases one by one, perhaps with some throttling/batching to minimize resource utilization.

Add Component Tests

Update license years

happy 2021

Tests don't appear if crate-type = cdylib

I'm very new to Rust so apologies if this is just me misunderstanding things. Thank you for making this plugin. Having a convenient test explorer is a helpful part of learning a new language.

If I run cargo new --lib foo I will get a new library with one test and that test properly shows up in the Test Explorer.

If I add to cargo.toml:

[lib]
crate-type = ["cdylib"]

The tests stop appearing in the Test Explorer.

I am adding that entry because it's what tutorials are telling me to do in order to compile to wasm. Details: https://doc.rust-lang.org/stable/edition-guide/rust-2018/platform-and-target-support/cdylib-crates-for-c-interoperability.html

Update windows PR agent spec

Setup CI Build

Tests duplicated in Test Explorer

I'm still fairly new to Rust and Cargo workspace setups, so this is probably a setup issue on my end but I'm not too sure.

Essentially, the tests for all my projects are showing twice:

In the above example issue-worker is a binary and elasticsearch-wrapper a library. I've setup a workspace with this folder structure. I'll be adding additional libraries in the future and want them all grouped together, hence the lib folder.

Cargo.toml [workspace]
issue-worker
  | Cargo.toml [package]
  | src
  | issue-worker.code-workspace
lib
  | elasticsearch-wrapper
      | Cargo.toml [package]
      | src
...
+ other non-Rust folders & files

I have a multi-root VSCode workspace with the 'issue-worker' and 'lib' folders. The reason for this is this workspace is sitting in a mono-repo that also has other non-Rust projects; I only want to see the relevant Rust folders.

// issue-worker.code-workspace
{
  "folders": [{
      "path": "."
    },
    {
      "path": "../lib"
    }
  ]
}

Improve Runner Performance

Related to #1 but tracking separately

The runner workflow can be optimized by better leveraging the structure of the tree node id's as direct input to the Cargo test filter when the run target is a suite instead of a test case. The newly refactored parsing functions will still be able to grab the associated result even with this change. This could possibly impact the implementation for #2 though

We should still pass the --exact flag to the test binaries when the target tree node is a test case

Add Integration Tests

Given how deeply reliant we are on cargo for both test discovery and execution, I think at a minimum our integration tests should run against a mix of operating systems, toolchains, cargo versions, etc.

The VS Code team recently announced that the vscode package was being split into separate ones for extension authoring and testing, so we'll need to pull that in as well.

Update Sonar Config

Sonar apparently deprecated support for forced language via the sonar.language property back in 4.5, and as of v7.7 it's officially no longer being recognized.

With our current configuration this is resulting in Sonar double counting our source TypeScript files and their respective JavaScript files emitted by the transpilation process.

The easiest way I've found to fix this is to simply add a property for inclusions:
sonar.inclusions=**/*.ts

Tree does not load with 80 tests but does with just 79 tests...

And not one more :)

Yesterday I add the 80th unit tests test and all tree was dissipated. I did some tests and if I remove one one test and I reload the tree come back.

michele@mdamico-laptop:~/sviluppo/rstest$ cargo test -p rstest --lib -- --list
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running target/debug/deps/rstest-8877d623afb4bd4c
parse::fixture::should::parse::empty_attributes: test
parse::fixture::should::parse::empty_fixtures: test
parse::fixture::should::parse::happy_path: test
parse::fixture::should::parse::should_accept_trailing_comma: test
parse::fixture::should::parse::some_literals: test
parse::rstest::should::parse_rstest_data::one_arg: test
parse::rstest::should::simple_case::integrated::should_parse_fixture_cases_and_matrix_in_any_order: test
parse::rstest::should::simple_case::matrix_cases::happy_path: test
parse::rstest::should::simple_case::matrix_cases::should_not_compile_if_empty_expression_slice: test
parse::rstest::should::simple_case::matrix_cases::should_parse_attributes_too: test
parse::rstest::should::simple_case::matrix_cases::should_parse_injected_fixtures_too: test
parse::rstest::should::simple_case::no_cases::empty_attributes: test
parse::rstest::should::simple_case::no_cases::empty_fixtures: test
parse::rstest::should::simple_case::no_cases::happy_path: test
parse::rstest::should::simple_case::parametrize_cases::case_could_be_arg_name: test
parse::rstest::should::simple_case::parametrize_cases::happy_path: test
parse::rstest::should::simple_case::parametrize_cases::one_simple_case_one_arg: test
parse::rstest::should::simple_case::parametrize_cases::should_accept_comma_at_the_end_of_cases: test
parse::rstest::should::simple_case::parametrize_cases::should_not_accept_invalid_separator_from_args_and_cases: test
parse::should::parse_attributes::integrated: test
parse::should::parse_attributes::one_simple_group: test
parse::should::parse_attributes::one_simple_ident: test
parse::should::parse_attributes::one_simple_type: test
parse::testcase::should::accept_arbitrary_rust_code: test
parse::testcase::should::get_description_also_with_more_args: test
parse::testcase::should::get_description_if_any: test
parse::testcase::should::parse_arbitrary_rust_code_as_expression: test
parse::testcase::should::raise_error_on_invalid_rust_code: test
parse::testcase::should::some_literals: test
parse::testcase::should::two_literal_args: test
parse::vlist::should::parse_values_list::forget_brackets: test
parse::vlist::should::parse_values_list::raw_code: test
parse::vlist::should::parse_values_list::raw_code_with_parsing_error: test
parse::vlist::should::parse_values_list::some_literals: test
render::fixture::should::clean_generics_in_partial_methods: test
render::fixture::should::implement_a_default_method_with_input_cleaned_fixture_signature_and_no_args: test
render::fixture::should::implement_a_get_method_with_input_fixture_signature: test
render::fixture::should::implement_partial_methods: test
render::fixture::should::maintains_no_pub_visibility: test
render::fixture::should::maintains_pub_visibility: test
render::fixture::should::use_default_return_type_if_any: test
render::fixture::should::use_partial_return_type_if_any: test
render::test::arg_2_fixture_should::call_arg: test
render::test::arg_2_fixture_should::not_add_mut: test
render::test::arg_2_fixture_should::use_passed_fixture_if_any: test
render::test::cases_should::add_a_test_case: test
render::test::cases_should::add_all_test_cases: test
render::test::cases_should::copy_user_function: test
render::test::cases_should::create_a_module_named_as_test_function: test
render::test::cases_should::left_pad_case_number_by_zeros: test
render::test::cases_should::mark_module_as_test: test
render::test::cases_should::mark_user_function_as_test: test
render::test::cases_should::starts_case_number_from_1: test
render::test::cases_should::use_description_if_any: test
render::test::complete_should::assign_all_case_combination_in_tests: test
render::test::complete_should::assign_same_case_value_for_each_test: test
render::test::complete_should::have_one_module_for_each_parametrized_case: test
render::test::complete_should::implement_exactly_4_tests_in_each_module: test
render::test::complete_should::implement_exactly_8_tests: test
render::test::complete_should::use_function_name_as_outer_module: test
render::test::fn_test_should::add_return_type_if_any: test
render::test::fn_test_should::include_given_function: test
render::test::generics_clean_up_should::not_remove_generics_used_in_arguments: test
render::test::generics_clean_up_should::remove_generics_not_in_output: test
render::test::matrix_cases_should::add_a_test_case: test
render::test::matrix_cases_should::add_a_test_cases_from_all_combinations: test
render::test::matrix_cases_should::copy_user_function: test
render::test::matrix_cases_should::create_a_module_named_as_test_function: test
render::test::matrix_cases_should::mark_module_as_test: test
render::test::matrix_cases_should::mark_user_function_as_test: test
render::test::matrix_cases_should::pad_case_index: test
render::test::matrix_cases_should::three_args_should_create_all_function_4_mods_at_the_first_level_and_3_at_the_second: test
render::test::matrix_cases_should::two_args_should_contain_a_module_for_each_first_arg: test
render::test::matrix_cases_should::two_args_should_create_all_modules_with_the_same_functions: test
render::test::matrix_cases_should::two_args_should_create_all_tests: test
render::test::matrix_cases_should::with_just_one_arg: test
render::test::resolver_should::return_none_for_unknown_argument: test
render::test::resolver_should::return_the_given_expression: test
utils::test::fn_args_has_ident_should: test
utils::test::fn_args_idents_should: test

80 tests, 0 benchmarks

Switch to Dependabot

Support VS Code workspace with no root-level Cargo.toml file

Tests are not displayed when working with more then one folder inside a VS workspace.

my workspace (test.code-workspace) looks like this

{
	"folders": [
		{
			"path": "a"
		},
		{
			"path": "b"
		}
	],
	"settings": {}
}

Create GitHub Templates

Will need:

• Issue Templates
  • Bug
  • Feature Request
  • Question
• Pull Request Template
• Contributing Template

Tests in the "Tests" folder are not discovered and runnable.

As of version 0.11.x the tests that are in the "tests" folder of a project are not discovered. Only unit tests in the same file as the code under test (lib) are discovered and runnable.

Add debug support

Migrate from `vscode` to `vscode-test` package

https://code.visualstudio.com/api/working-with-extensions/testing-extension#migrating-from-vscode