Add `test` command to run any unit test #1092

xavdid · 2023-06-25T05:37:20Z

Per discussion in this forum post, I've added a test command to the exercism CLI. Much like the universal test runner it's inspired by, its goal is to be able to run the basic unit test suite for any exercism exercise.

It does this by:

reading .exercism/metadata.json to get the track name
doing a lookup in a table which maps track name => a test command (and some configuration; see below)
maybe reading .exercism/config.json to get test file name(s) and including them
including any args from exercism test
Using go's exec.Command to run and return info about the exit code

Types of Tests

Based on my (very brief) sampling of exercism tracks, there are 2 main ways tests are run:

Using a language-wide common command (e.g cargo test, go test, lien test, etc)
A single test file invoked like any program of that language (e.g. ruby lasagna_test.rb)

So, the TestConfiguration struct covers both of those cases (by including an option to append the test file(s) to the command).

The other configuration option aids in arg passing. Some language tools (namely cargo) expect arguments to the test command to be after a double dash (--). Unfortunately, so does Cobra, the go arg parser. So, I was running into the following trying to run rust tests with --include-ignored:

exercism test --include-ignored: --include-ignored is not a valid flag for the test command
exercism test -- --include-ignored: --include-ignored is not a valid flag for cargo, put it behind a --
exercism test -- -- --include-ignored: works as expected

This isn't great UX though, so I added an option for languages to be able to ask that args to their test runner be put behind an implied --. This way, the rust command works when run as option 2 above (which is in line with most other languages).

TODO

add tests
add more languages (I don't know that we need to ship with 100% coverage, but the top 20 most popular languages would be great)
add docs / changelog

github-actions · 2023-06-25T05:37:33Z

Hello. Thanks for opening a PR on Exercism. We are currently in a phase of our journey where we have paused community contributions to allow us to take a breather and redesign our community model. You can learn more in this blog post. As such, all issues and PRs in this repository are being automatically closed.

That doesn't mean we're not interested in your ideas, or that if you're stuck on something we don't want to help. The best place to discuss things is with our community on the Exercism Community Forum. You can use this link to copy this into a new topic there.

Note: If this PR has been pre-approved, please link back to this PR on the forum thread and a maintainer or staff member will reopen it.

MatthijsBlom · 2023-06-25T08:24:44Z

cmd/test.go

+	autoSeparateArgs bool
+}
+
+var testConfigurations = map[string]TestConfiguration{


It might make more sense to read this data from a user-configurable place: a user might want to modify the standard command, or add a missing one.

Sure, I can look into that.

What configuration do you expect users to do? Replace the command entirely, always add specific arguments, etc. Off the top of my head, I'm thinking we add a field to config.json that covers cases we want to start with (testCommand, args, etc). Or do you mean something central? They could maybe override commands (and args, etc) per-track in a central place.

I think it would make sense for it to be user-overridable, but to include these defaults in the CLI. That way the command will work out of the box for most people without having to modify the config file, but the option is there if people want it.

Here's a thought: use ~/.config/exercism/user.json
Extend exercism configure

exercism configure --test --track go --script "go test" exercism configure --test --track ruby --script "(cat <<'END' sh -c ' for t in *_test.rb; do gawk -i inplace '1; /< Minitest::Test/ {print " def skip; end"}' "$t" ruby "$t" done ' END )"

And then ~/.config/exercism/user.json contains

{ "apibaseurl": "https://api.exercism.io/v1", "token": "my-uuid", "workspace": "/Users/glennj/src/exercism/exercism.io" "testing": { "go": "go test", "ruby": " sh -c '\n for t in *_test.rb; do\n gawk -i inplace '1; /< Minitest::Test/ {print \" def skip; end\"}' \"$t\"\n ruby \"$t\"\n done\n '" } }

I'm not opposed to making it so configurable, but I wonder if we shouldn't release a simpler version initially and then add configuration options later?

With the universal test runner, one of my main design goals was "it just works". I think being able to run every test suite out of the box without configuration is a great starting point and will cover a lot of use cases and we can iterate from there.

CONTRIBUTING.md

cmd/test.go

ErikSchierboom · 2023-07-07T09:51:06Z

cmd/test.go

+	testConf, ok := workspace.TestConfigurations[track]
+
+	if !ok {
+		return fmt.Errorf("test handler for the `%s` track not yet implemented. Please see HELP.md for testing instructions", track)


Nice to point to the HELP.md file

I also noticed that every track's testing instructions are at https://exercism.org/docs/tracks/{TRACK}/tests, so I could link out to that too (or instead).

You could, but I think HELP.md is even better in this case

I wonder if we should maybe no use "test handler", which is somewhat technical, but use a more functional description. Maybe:

Suggested change

return fmt.Errorf("test handler for the `%s` track not yet implemented. Please see HELP.md for testing instructions", track)

return fmt.Errorf("This track does not yet support running tests via the CLI. Please see HELP.md for testing instructions", track)

yeah, great call. I went with the \"%s\" track does not yet support running tests using the Exercism CLI. Please see HELP.md for testing instructions, to be clear tests can be run via a CLI, just not the exercism one. Also I kept the track name in, since that reminds them where they are (to reduce confusion vs "this track")

workspace/exercise_config.go

ErikSchierboom · 2023-07-07T09:56:05Z

workspace/exercise_config.go

+}
+
+// NewExerciseMetadata reads exercise metadata from a file in the given directory.
+func NewExerciseConfig(dir string) (*ExerciseConfig, error) {


I like how this is now "a thing". Maybe the getExerciseSolutionFiles function in workspace/submit.go can also be updated once this PR is merged.

yeah! that would make sense.

workspace/test_configurations.go

xavdid

Ok, I think that covers the feedback we had, and testing seems promising.

The thing I'm not confident about is the best way to test it. In my python version, I focused mostly on two cases:

given a test configuration, does it match a specific directory setup
given a specific set of files, what's the resulting command when the top-level command is run

This is a little different, since we don't have a matching system. As long as reading the config works across tracks, this will just work. I think we'd want to:

verify that test file replacement is happening
verify that windows commands are being prioritized if available
verify we can read configs (and error handling happens correctly)

I haven't done much unit testing in go, so I'd love to defer to someone else on these if it's something you (or another contributor) has a lot of experience with. I was playing with mocking the syscalls and directory lookups, but wasn't having much luck; there may be a better way to go about it.

xavdid · 2023-07-12T05:06:32Z

cmd/cmd_test.go

-// 	MockInteractiveResponse: "first-input\nsecond\n",
-// }
+//
+//	cmdTest := &CommandTest{


CI was complaining about this block, so I ran go fmt ./... and this was the change. I realize you want to keep the PR focused, but I also assume you want to keep the CI green

xavdid · 2023-07-12T05:09:56Z

workspace/test_configurations.go

+		WindowsCommand: "test.ps1",
+	},
+	"coffeescript": {
+		Command: "jasmine-node --coffee {{test_files}}",


I experimented with putting {{test_files}} in a const (which would improve the replacement code), but it made writing the commands less clear (one of "ruby " + TEST_FiLES or fmt.Sprintf("ruby %s", TEST_FILES) or injectTestFilesPlaceholder("ruby %s"), all of which seemed to defeat the point).

As written, there's a higher chance that someone adding a new command will typo the placeholder and the replacement won't happen, but it provides the most clarity when reading the actual commands.

I think this is nice!

ErikSchierboom · 2023-07-12T11:45:40Z

I'd like someone with Go experience to look at this (@ekingery or @junedev perhaps?).

I'm doing some functional testing:

Simple command (tested with C#): works
Command with {{test_files}} placeholder (tested with CoffeeScript and Ruby): work
Windows/Linux commands: I don't have Go on my Windows machine, but the Linux bit works. Someone else should test this on Windows

ErikSchierboom · 2023-07-12T11:45:59Z

workspace/test_configurations.go

+		Command:        "test.sh",
+		WindowsCommand: "test.ps1",


Suggested change

Command: "test.sh",

WindowsCommand: "test.ps1",

Command: "./test.sh",

WindowsCommand: "pwsh test.ps1",

I've updated, but was just copying from the docs. they may need to be updated: https://exercism.org/docs/tracks/cobol/tests#h-windows

junedev

@ErikSchierboom The Go code itself looks fine to me. Can't comment on general code organization in the codebase or anything like that though.

Sidenote: On a conceptual level, I am not sure whether I am a big fan of this feature as we take away learning about how to actually run tests in the language. Even if it means just learning that in this language usually a make file is used or "there is a built-in test runner" like in the case of Go. I am ok with this being merged but I wanted to mention it.

xavdid · 2023-07-16T22:12:48Z

Ok, I've added little unit tests for the exercise config reading. It doesn't look like it's easy to test the windows behavior in a unit test (based on this SO answer), but I have a windows computer I can probably install go on and try it out.

I am not sure whether I am a big fan of this feature as we take away learning about how to actually run tests in the language.

That's a great point! I got similar feedback on the standalone project. I've added a logline that shows exactly what's being run, so at least it's more clear what's happening:

% ~/projects/exercism-cli/testercism test
--> ruby lasagna_test.rb
Run options: --seed 33076

# Running:
....

If we're comfortable (enough to move forward) with the level of unit tests written, I think the last big tasks is go through the rest of the "easy" and "medium" language tracks and add them into the test configurations. I've been saving that for last so the PR doesn't get too unwieldy, but can grab it tomorrow.

xavdid · 2023-07-17T07:08:31Z

Ok, I've added more tests than I thought I'd be able to. I saw that CI actually has a windows runner, so I added a test that pulls the windows command. I also got some file-based tests working by actually writing and removing files. It's in the test directory, which I don't love, but it should be fine.

The last thing is the actual test command itself, but that would require more refactoring to mock out the exec.Command call. The rest of it has enough tests that I'm personally comfortable shipping this PR as stands (+ the rest of the easy commands, as mentioned; I'll add those after the rest is ✅)

Thanks for bearing with me y'all!

ErikSchierboom · 2023-07-18T10:37:52Z

@ekingery Are you up for a code review? I'm especially interested in the test coverage.

ekingery

Thanks for the contribution, @xavdid! I'm rusty now in both Go and this CLI codebase, however everything looks in line with what I'd expect and the test coverage is solid. Might be nice to add coveralls to this project for an empirical assessment on test coverage. All that said, 👍 from me.

ErikSchierboom · 2023-07-20T07:02:08Z

Thanks for the reviews everybody!

ErikSchierboom · 2023-07-20T07:05:29Z

Really happy about the state of this PR!

There are two things left to do:

Fix Windows CI
Add the test configurations for all tracks

xavdid · 2023-07-20T07:42:45Z

Ah, pesky platform-specific error message. I think I fixed CI in 540bef5- if you could give that another run, I'd appreciate it! I'll get the rest of the test commands in tomorrow.

xavdid · 2023-07-21T05:14:30Z

Ok, I've added the remaining tracks (and more than I thought I'd get)!

Work is split into a few last commits:

I added all the simple tests in fc6b22c
added bash-based tests and some sensible defaults for ambiguous tracks (d and clojure) in dcdf168
added (c *ExerciseConfig) GetSolutionFiles() and its tests (which closely mirrors GetTestFiles()) to power the prolog track (which needs both solution and test files in the command) in dcdf168
updated the changelog in 8d18c39

@ErikSchierboom unless anything from those jumps out at you, I think we're all set!

The only remaining tracks are scheme (two tools mentioned in docs, unclear which a user will likely have installed) and cpp + fortran (complex, multi-stage setup process). My full notes are in Airtable if you need to refer back to them.

ErikSchierboom · 2023-07-21T11:58:19Z

@ErikSchierboom unless anything from those jumps out at you, I think we're all set!

I'm quite busy today, so it will be next week (wednesday at the earliest). Sorry!

…rators

xavdid · 2023-07-26T07:59:45Z

Ok, I debugged the tests on my windows machine and got them working in 238b572. Turns out windows won't delete a folder if it's got an open descriptor somewhere and I had neglected to close after write. Mac had no issue with this, so it was news to me. Also, I was using path.join instead of filepath.join in a couple of tests.

That CI should be good to go. 🤞

ErikSchierboom

Works like a charm! Just a couple of minor comments (and CI is failing)

ErikSchierboom · 2023-07-26T07:30:38Z

cmd/test.go

+	testConf, ok := workspace.TestConfigurations[track]
+
+	if !ok {
+		return fmt.Errorf("test handler for the `%s` track not yet implemented. Please see HELP.md for testing instructions", track)


I wonder if we should maybe no use "test handler", which is somewhat technical, but use a more functional description. Maybe:

Suggested change

return fmt.Errorf("test handler for the `%s` track not yet implemented. Please see HELP.md for testing instructions", track)

return fmt.Errorf("This track does not yet support running tests via the CLI. Please see HELP.md for testing instructions", track)

ErikSchierboom · 2023-07-26T08:09:08Z

cmd/test.go

+		cmdParts = append(cmdParts, args...)
+	}
+
+	fmt.Printf("--> %s\n", strings.Join(cmdParts, " "))


I really like the logging! My only concern is that it might be too subtle for the student to notice. Maybe we could make it more explicit? To instead of --> <command>, something like Running tests via: <command> or Running test command: <command>

Sure! updated to:

Running tests via `<command>`\n\n

which makes it clear exactly what's running and gives it some space to breathe

xavdid · 2023-07-26T08:37:53Z

Ok, addressed that feedback. CI should be good to go as well!

ErikSchierboom · 2023-07-26T09:16:01Z

workspace/test_configurations.go

+	return cmd, nil
+}
+
+var TestConfigurations = map[string]TestConfiguration{


I've just done a quick double check to see which active tracks are missing.
This is the list of missing tracks:

abap

common-lisp

cpp

delphi

fortran

objective-c

pharo-smalltalk

plsql

powershell

r

scheme

unison

vimscript

Could you double check these tracks? If they're not supported, it might be useful to add a comment somewhere noting that those tracks are not supported (and why)

Sure, added in ad33864! I've confirmed that most of the remaining tracks are N/A (tests are run in IDE, etc).

For common-lisp, I used

sbcl --load "${slug}-test" \ --eval "(exit :code (if (${slug}-test:run-tests) 0 5))"

That assumes a particular distribution: there are several suggested on the track's intstallation page.

For fortran, I have this fish snippet

if not test -d ./.exercism echo run me from the exercise root >&2 return 1 end mkdir -p build cd build test -d ./testlib; or cmake -G "Unix Makefiles" .. make; and ctest -V cd ..

R is just

Rscript test_*.R

R is just
Rscript test_*.R

Could you update the configuration to use this command? I can confirm that this is also how the test runner does it.

Ah, good call! I didn't even think about the test runners - I've been going off the public docs

ErikSchierboom · 2023-07-27T07:27:03Z

workspace/test_configurations.go

 	"vbnet": {
 		Command: "dotnet test",
 	},
+	// vimscript: tests are run from inside a vim session


Looking at how the test runner does it, it looks like this might be possible. Could you double-check?

While this does seem to work, the output is super long and ugly. There doesn't seem to be a --quiet flag and I'm disinclined to ship it as is:

% vim -XN -i NONE -c ":so hello_world.vim" -c "Vader! hello_world.vader" Vader note: cannot print to stderr reliably/directly. Please consider using Vim's -es/-Es option (mode=n). VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Apr 15 2023 04:26:46) macOS version - arm64 Included patches: 1-1424 Compiled by [email protected] Normal version without GUI. Features included (+) or not (-): +acl -dnd +listcmds +postscript +termresponse -arabic -ebcdic +localmap +printer +textobjects +autocmd -emacs_tags -lua -profile +textprop +autochdir +eval +menu -python +timers -autoservername +ex_extra +mksession -python3 +title -balloon_eval +extra_search +modify_fname +quickfix -toolbar -balloon_eval_term -farsi +mouse +reltime +user_commands -browse +file_in_path -mouseshape -rightleft -vartabs ++builtin_terms +find_in_path +mouse_dec -ruby +vertsplit +byte_offset +float -mouse_gpm +scrollbind +vim9script +channel +folding -mouse_jsbterm +signs +viminfo +cindent -footer +mouse_netterm +smartindent +virtualedit -clientserver +fork() +mouse_sgr -sodium +visual +clipboard -gettext -mouse_sysmouse -sound +visualextra +cmdline_compl -hangul_input +mouse_urxvt +spell +vreplace +cmdline_hist +iconv +mouse_xterm +startuptime +wildignore +cmdline_info +insert_expand +multi_byte +statusline +wildmenu +comments +ipv6 +multi_lang -sun_workshop +windows +conceal +job -mzscheme +syntax +writebackup +cryptv +jumplist +netbeans_intg +tag_binary -X11 +cscope -keymap +num64 -tag_old_static -xfontset +cursorbind +lambda +packages -tag_any_white -xim +cursorshape -langmap +path_extra -tcl -xpm +dialog_con +libcall -perl +termguicolors -xsmp +diff +linebreak +persistent_undo +terminal -xterm_clipboard +digraphs +lispindent +popupwin +terminfo -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" defaults file: "$VIMRUNTIME/defaults.vim" fall-back for $VIM: "/usr/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X_UNIX -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -L/usr/local/lib -o vim -lm -lncurses -liconv -framework Cocoa Starting Vader: 1 suite(s), 1 case(s) Starting Vader: /Users/david/projects/exercism/vimscript/hello-world/hello_world.vader (1/1) [EXECUTE] Say Hi! Success/Total: 1/1 Success/Total: 1/1 (assertions: 1/1) Elapsed time: 0.01 sec.

Do you think it's common that users are running this standalone vs inside vim itself?

Probably not. The verbosity is indeed a bit much. Let's leave it out

ErikSchierboom · 2023-07-27T07:28:20Z

workspace/test_configurations.go

+	return cmd, nil
+}
+
+var TestConfigurations = map[string]TestConfiguration{


R is just
Rscript test_*.R

Could you update the configuration to use this command? I can confirm that this is also how the test runner does it.

ErikSchierboom · 2023-07-27T07:31:39Z

workspace/test_configurations.go

@@ -90,6 +92,8 @@ var TestConfigurations = map[string]TestConfiguration{
 	"coffeescript": {
 		Command: "jasmine-node --coffee {{test_files}}",
 	},
+	// common-lisp: tests are loaded into a "running Lisp implementation", not the CLI directly
+	// cpp: tests are mostly run via IDE; only linux seems to support `make`. There's also a more complex test creation process (using `CMake`)


Could we do cmake and then make via &&? See https://github.com/exercism/cpp-test-runner/blob/main/bin/run.sh#L43 We'd have to test if this works in Windows of course.

It won't work as written. It works if I run cmake . && make manually, but because we're passing the command into a single exec.Command, it's being run as cmake . make, and make is ignored as an unknown path:

CMake Warning: Ignoring extra path from command line: "make"

To make that work, we'd need to make every command a slice of strings (most of which will only have 1 item) and then run each in order (which will work cross-platform).

I think that's a reasonable improvement to make, but I'd recommend putting it in its own PR; this one has gotten big. I also have no idea if/how this build script works on windows- I left off the -G "Unix Makefiles" part of the command and I have no idea how important that is. Verifying this is probably best left to someone who knows more about those tracks. I'd rather ship a TODO than a solution we're not sure works

Actually, it looks like the cmake portion is 1-time setup. Once it's run successfully, the only thing you need to run tests is make. I think it's reasonable to treat the cmake portion as user-required setup/installation and the actual test run as make. I'll update accordingly.

workspace/test_configurations.go

sanderploegsma · 2023-07-27T19:32:25Z

testercism

I was just appreciating this new feature and noticed this file was added. I’m assuming it wasn’t meant to be committed so I thought I’d point it out 🤓

good call, removed 😅

ErikSchierboom

It all looks really good! There is one final thing to do, and that is to remove the committed testercism binary from the history. It was added in a9c1fb1 and removed in 2991cfe, but that still means it is in the Git repo.

What you'll need to do is to an interactive rebase and edit the commit in which it was added to make sure that commit doesn't add the file and remove the commit in which the file was removed (which is unneeded).

Are you familiar with interactive rebasing? I tried doing it for you, but I can't push to your branch (it's a setting that you need to enable somewhere).

ErikSchierboom · 2023-07-28T06:56:52Z

workspace/test_configurations.go

 	"vbnet": {
 		Command: "dotnet test",
 	},
+	// vimscript: tests are run from inside a vim session


Probably not. The verbosity is indeed a bit much. Let's leave it out

xavdid · 2023-07-28T07:24:21Z

Ok, I've done the interactive rebase! I amended a9c1fb1 and dropped 2991cfe and then force pushed the result.

I could have sword I checked "allow edits by maintainers", but I can't the setting on the PR now.

Let me know how that looks!

ErikSchierboom · 2023-07-28T07:28:13Z

erik@schierheim:~/exercism/cli$ git log --all --full-history -- testercism
erik@schierheim:~/exercism/cli$

Nice! That looks good. Once CI is green, I'll merge. Thank you for this great contribution!

xavdid · 2023-07-28T07:31:56Z

All right! Looks like we're all set.

You're very welcome, glad we got it over the line. Thank you for your patience with the whole process - this one was a journey 😅

ErikSchierboom · 2023-07-28T07:44:43Z

@xavdid Sorry that it took a bit long, but this is a big feature and one that many students will benefit from! 🎉

ErikSchierboom · 2023-07-28T07:45:07Z

@kytrinyx Could we maybe do the release together, to make sure I have all the right permissions?

kytrinyx · 2023-07-28T10:35:26Z

@ErikSchierboom For sure! Let's see what we can do this afternoon.

`test` command was supported since v3.2.0, see a8ffc31 (Add `test` command to run any unit test (\exercism#1092), 2023-07-28)

`test` command was supported since v3.2.0, see a8ffc31 (Add `test` command to run any unit test (\#1092), 2023-07-28)

xavdid added 2 commits June 24, 2023 21:58

add test command

2abd3dd

tweak docs

0f8f7a8

github-actions bot closed this Jun 25, 2023

MatthijsBlom reviewed Jun 25, 2023

View reviewed changes

ErikSchierboom reopened this Jul 5, 2023

xavdid added 3 commits July 6, 2023 00:07

move test command into its own function

3c2c3b8

add support for platform-specific commands

92b9252

moved test configurations into a file

345a627

ErikSchierboom reviewed Jul 7, 2023

View reviewed changes

xavdid added 3 commits July 11, 2023 00:00

formatting

f0e69d0

updates from code review

7844519

add placeholder replacement for test files

7613a46

xavdid commented Jul 12, 2023

View reviewed changes

xavdid marked this pull request as ready for review July 12, 2023 05:21

ErikSchierboom reviewed Jul 12, 2023

View reviewed changes

junedev reviewed Jul 16, 2023

View reviewed changes

xavdid added 2 commits July 16, 2023 14:28

add exercise_config tests

5545bc7

print command that's running

7169a7c

add more tests

c4bc591

ekingery approved these changes Jul 18, 2023

View reviewed changes

fix message assertions in certain tests

540bef5

add many test commands

fc6b22c

xavdid added 3 commits July 20, 2023 20:48

add bash commands and some ambiguous tracks

dcdf168

add prolog config

ffe0f04

update changelog

8d18c39

xavdid added 2 commits July 26, 2023 00:53

ensure files are closed and error messages use platform-specific sepa…

238b572

…rators

close a few more file descriptors to be safe

cb92807

ErikSchierboom reviewed Jul 26, 2023

View reviewed changes

update CLI output text

0dc184e

ErikSchierboom reviewed Jul 26, 2023

View reviewed changes

add comments for unimplemented test tracks

ad33864

ErikSchierboom reviewed Jul 27, 2023

View reviewed changes

sanderploegsma reviewed Jul 27, 2023

View reviewed changes

ErikSchierboom reviewed Jul 28, 2023

View reviewed changes

xavdid added 3 commits July 28, 2023 00:20

add powershell track

33cf452

add tests for the R language

9da7a31

Add fortran and cpp

d790992

ErikSchierboom merged commit a8ffc31 into exercism:main Jul 28, 2023

iHiD added x:size/massive Massive amount of work x:rep/massive Massive amount of reputation labels Aug 10, 2023

muzimuzhi added a commit to muzimuzhi/exercism-cli that referenced this pull request Aug 18, 2024

Add test command to Shell completions

812de2e

`test` command was supported since v3.2.0, see a8ffc31 (Add `test` command to run any unit test (\exercism#1092), 2023-07-28)

ErikSchierboom pushed a commit that referenced this pull request Aug 20, 2024

Add test command to Shell completions (#1156)

20d58b1

`test` command was supported since v3.2.0, see a8ffc31 (Add `test` command to run any unit test (\#1092), 2023-07-28)

	return fmt.Errorf("test handler for the `%s` track not yet implemented. Please see HELP.md for testing instructions", track)
	return fmt.Errorf("This track does not yet support running tests via the CLI. Please see HELP.md for testing instructions", track)

Add test command to run any unit test #1092

Add test command to run any unit test #1092

Conversation

xavdid commented Jun 25, 2023 • edited Loading

Types of Tests

TODO

github-actions bot commented Jun 25, 2023

Choose a reason for hiding this comment

xavdid Jun 25, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xavdid left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ErikSchierboom commented Jul 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

junedev left a comment

Choose a reason for hiding this comment

xavdid commented Jul 16, 2023

xavdid commented Jul 17, 2023

ErikSchierboom commented Jul 18, 2023

ekingery left a comment

Choose a reason for hiding this comment

ErikSchierboom commented Jul 20, 2023

ErikSchierboom commented Jul 20, 2023

xavdid commented Jul 20, 2023 • edited Loading

xavdid commented Jul 21, 2023

ErikSchierboom commented Jul 21, 2023

xavdid commented Jul 26, 2023

ErikSchierboom left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xavdid commented Jul 26, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

glennj Jul 26, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xavdid Jul 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xavdid Jul 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ErikSchierboom left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xavdid commented Jul 28, 2023

ErikSchierboom commented Jul 28, 2023

xavdid commented Jul 28, 2023

ErikSchierboom commented Jul 28, 2023

ErikSchierboom commented Jul 28, 2023

kytrinyx commented Jul 28, 2023

Add `test` command to run any unit test #1092

Add `test` command to run any unit test #1092

xavdid commented Jun 25, 2023 •

edited

Loading

xavdid Jun 25, 2023 •

edited

Loading

xavdid commented Jul 20, 2023 •

edited

Loading

glennj Jul 26, 2023 •

edited

Loading

xavdid Jul 27, 2023 •

edited

Loading

xavdid Jul 27, 2023 •

edited

Loading