nlamirault / gotest.el

Emacs mode to go unit test command line tool

gotest.el

• Master :
• Develop:

Run Go tests and programs from Emacs (>= 24.3)

Installation

The recommended way to install gotest.el is via MELPA:

M-x package-install gotest.el

or Cask:

(depends-on "gotest.el")

Usage

The following interactive commands can be run via M-x or bound to a key of your choice.

All go-test-* functions can optionally configure the buffer-local go-test-args variable to pass additional arguments. Or, by using a prefix command, you will be prompted for arguments. For example: C-u M-x go-test-current-test.

When using the '_ prefix arg with any of the go-test-* or go-run functions, the most recent arguments from history will be used without prompting. For example: M-- M-x go-run.

go-test-current-test

Launch unit tests for the current test.

go-test-current-test-cache

Rerun the current test.

go-test-current-file

Launch unit tests and examples for the current file

go-test-current-project

Launch unit tests and examples for the current project.

go-test-current-coverage

Launch unit tests coverage for the current project.

go-test-current-benchmark

Launch go benchmark on current benchmark

go-test-current-file-benchmarks

Launch go benchmark on current file

go-test-current-project-benchmarks

Launch go benchmark on current project

go-run

Launch program via go run. Optionally configure the buffer-local go-test-args variable to pass additional arguments. Or, by using a prefix command, you will be prompted for arguments. For example: C-u M-x go-run.

Be sure to make use of minibuffer history (C-r) to recall recent arguments to go run. And remember that the M-- prefix can be used in combination with your go run key binding to use the most recent arguments without prompting. The go file is included in history, so you can go-run from history regardless of which buffer you are currently visiting.

Example key bindings

You can create some key bindings with these commands:

(define-key go-mode-map (kbd "C-x f") 'go-test-current-file)
(define-key go-mode-map (kbd "C-x t") 'go-test-current-test)
(define-key go-mode-map (kbd "C-x p") 'go-test-current-project)
(define-key go-mode-map (kbd "C-x b") 'go-test-current-benchmark)
(define-key go-mode-map (kbd "C-x x") 'go-run)

Addons

Gb

If your project use gb, gotest will use this tool to launch unit tests.

Development

Cask

gotest.el use Cask for dependencies management. Install it and retrieve dependencies :

$ curl -fsSkL https://raw.github.com/cask/cask/master/go | python
$ export PATH="$HOME/.cask/bin:$PATH"
$ cask

Testing

• Launch unit tests from shell

  $ make clean test

• Using overseer :

Keybinding	Description
C-c , t	launch unit tests from buffer
C-c , b	launch unit tests
C-c , g	launch unit tests with tag (find, regexp, ...)

• Tips:

If you want to launch a single unit test, add a specify tag :

(ert-deftest test-foobar ()
  :tags '(current)

And launch it using : C-c , g and specify tag : current

Support / Contribute

See here

Changelog

A changelog is available here.

License

See LICENSE.

Contact

Nicolas Lamirault [email protected]

gotest.el's Issues

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Ignored or Blocked

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

• Update actions/setup-python action to v4

Detected dependencies

github-actions

.github/workflows/elisp.yml

• actions/checkout v3
• actions/setup-python v3

.github/workflows/release-drafter.yml

• release-drafter/release-drafter v5

---

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

CVE-2022-28948 (High) detected in github.com/go-yaml/yaml-v3.0.0

CVE-2022-28948 - High Severity Vulnerability

Vulnerable Library - github.com/go-yaml/yaml-v3.0.0

YAML support for the Go language.

Dependency Hierarchy:

• github.com/stretchr/testify/suite-v1.7.0 (Root Library)
  • github.com/stretchr/testify/require-v1.7.0
    • github.com/stretchr/testify/assert-v1.7.0
      • ❌ github.com/go-yaml/yaml-v3.0.0 (Vulnerable Library)

Found in base branch: master

Vulnerability Details

An issue in the Unmarshal function in Go-Yaml v3 causes the program to crash when attempting to deserialize invalid input.

Publish Date: 2022-05-19

URL: CVE-2022-28948

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-hp87-p4gw-j4gq

Release Date: 2022-05-19

Fix Resolution: 3.0.0

---

Step up your Open Source Security Game with Mend here

support -count

I think it would be reasonable to have arg work as count eg

C-10 M-x go-test-current-test

will result in appending -count=10 to the test run command.

This will also work nicely with the go 1.10 caching since the way to override it is to to

go test ./... -count=1

Can't install package in melpa stable

Error:

Debugger entered--Lisp error: (error "Need package `f-0.18.0', but only 0.17.3 is available")
  signal(error ("Need package `f-0.18.0', but only 0.17.3 is available"))

Dependencies: emacs 24.3 / f 0.18.0 / go-mode 1.3.1 / s 1.10.0

The latest version of f in melpa stable is: 0.17.3: https://stable.melpa.org/#/f

Some generic error regexps match

When running tests that log with a custom format, I see that go-test-mode wrongly buttonizes random lines that contain references to file names. Here's an example log line that gets fontified:

[54546|github.com/antifuch/something/storage.TestSomething 86295abcfd4c1629>3f25b6acce436923]   [err_kyyLxFeB6zZN0Nra]  /Users/asf/Hacks/go/src/github.com/antifuchs/something/controller.go:106: [trace] Couldn't perform action

I'd like to define a regexp matching the references contained in these errors, but the following doesn't cause a button to be created:

(add-to-list 'compilation-error-regexp-alist-alist
               '(go-test-my-log-format "\[err_[[:alnum:]]+\]  \\(/.+\\.go\\):\\([0-9]+\\): .*" 1 2))
  (add-to-list 'go-test-compilation-error-regexp-alist 'go-test-my-log-format)

This error doesn't match any of the regexes on go-test-compilation-error-regexp-alist-alist (but matches some referenced by the default compilation-error-regexp-alist). As a workaround, I've started doing this:

(add-to-list 'go-test-mode-hook
               (defun asf--go-test-mode-setup-hook ()
                 (add-to-list (make-local-variable 'compilation-error-regexp-alist) 'go-test-my-log-format)))

...and this aligns regexes to correctly buttonize this output; This leads me to suspect gotest picks up the default error regexps from compilation-error-regexp-alist. Is this workaround what I should be doing?

Add support for testify suite

...

Default to previously set coverage file

Subject says it all, when running tests with coverage, don't have the user browse around for the coverage report file every time.

go-test-current-coverage overwrites file with "mode: set"

When I ran M-x go-test-current-coverage and chose which file to test, it overwrote the file with the text mode:set. Then the test proceeded to fail because that text is not a valid Go file.

Improve usability when executed from a non-test file.

When go-test-current-file or go-test-current-file-benchmarks is invoked from a non-test file they could run tests from the corresponding test file. E.g. if the current file is file.go then go-test-current-file should run tests from file_test.go.

go-test-current-test can look at the function name. E.g. if the current function is Foo then it could run TestFoo if it exists.

go-test-current-test cache the previous command

Preface

It would be worth to have a dedicated function to execute the previous run command in the same state.

Usage case

Following TDD you may have a lot of iterations of running the working test and fixing it. And instead of placing the cursor on the test body and back every time, you may run the previous test using a shortcut mapped to an emacs function (e.g. go-test-current-test-cache) which restores the previous state.

`go-test-args` has no effect

It appears customizing go-test-args has no effect currently, no matter what it is set to the command executed is go test -file=...

Cannot detect environment variables

My environment variables for my project settings are initialized when a new terminal tap is opened. In this case whenever I test something with go-test-current-test it can never find the environment file.

Is there any parameters to set up gotest.el to run from ansi-term in emacs? Or is there anyway I could initialise go test with a shell script?

Always show `Compiling` on modeline

Hi,
I am using gotest everyday, but I found it always shows Compiling on modeline for every files, even after the tests are completed.

GNU Emacs 26.0.90, macOS 10.13.2

The screenshot is below. Please check and fix. Thanks!

Edit the go test command from the Go Test buffer

I'd like to have a quick way to edit the last run command when in the *Go Test* buffer. I haven't found this documented so I had to look at the source. What I want is basically C-u g which prompts me to edit the current command before running it again. That way, I can edit flags temporarily without having to know more about how gotest-mode is configured. Ideally I'd want to bind this to something shorter like e (this is what ledger-mode does in its report buffers)

I'm wondering if you'd be open to adding a keybinding for that command and making it configurable. Or maybe just adding something to the readme about it? Happy to help with a PR.

Support compilation mode hyperlinks for more testify cases

Hi @nlamirault

I use testify/(require|assert) a lot at work and was wondering if we could improve go-test's compilation output to match some of its error messages. In particular given:

main.go:

package main

func addOne(x int) int {
	return x + 0
}

main_test.go:

package main

import (
	"github.com/stretchr/testify/assert"
	"testing"
)

func TestAddOne(t *testing.T) {
	x := addOne(1)

	assert.Equal(t, 2, x)
}

I get output like this:

I would like the Error Trace: filename.go:linenumber line to be matched by the compilation-error-regexp-alist.

I thought it would be just a matter of adding something like

	(go-test-testify2 . ("^\tError Trace:\t\\([[:alnum:]-_/.]+\\.go\\):\\([0-9]+\\)$" 1 2))) ;; testify package assert

here and then here.

However, I can't seem to get it to work; I haven't done much with compilation modes regexp before so I was wondering if I was missing something obvious, e.g. about the order I'm evaluating my patches or something that stops this from working.

Do you have an idea of how to get this working properly? I'm happy to submit a PR if I can figure it out, but documentation for this functionality is a bit scattered and seems to differ between emacs, xemacs, emacs < v22 vs > 22, etc. etc. so I'm not too sure about how to debug why this isn't doing what I want.

cheers!

GO111MODULE=on if go.mod found

When running tests in a modern Go project, GO111MODULE=on should be set for the dependencies to be fetched automatically. Perhaps behind a defcustom. Any thoughts?

go-test-current-test can run more than one test

An argument to go test -run is a regex, so given the following source code:

package main

import (
    "fmt"
    "testing"
)

func TestA(t *testing.T) {
    fmt.Println("test a")
}

func TestAB(t *testing.T) {
    fmt.Println("test ab")
}

and running go-test-current-test inside TestA will run both TestA and TestB

Can I set go-test-args globally in emacs config?

go-test-* Always opens a new buffer

When running any of the go-test-* (like go-test-current-file or go-test-current-project) the Go Test buffer appears in a new window all the time, quickly filling my Emacs frame, also, the old window with the Go Test buffer moves to some other buffer and it gets messy very rapidly.

Is it possible to have the Go Test buffer always appear in the same window and not spliting my frame at all after a Go Test buffer is already visible?

go-test-current-project is only running the test on parent directory

When I have a Go project with nested packages, running the go-test-current-project is only running all the tests on parent directory.

Example

Project path: ~/Code/go-project
Current buffer: ~/Code/go-project/v2/handlers/get_handler_test.go

Expectation

When running go-test-current-project it should run tests for the whole project (~/Code/go-project)

Actual

It is only testing all the tests below ~/Code/go-project/v2/handlers

Add support for vendoring

Support vendoring functionnality : Go 1.5 [1] and gb [2]

[1] : https://blog.golang.org/go1.5
[2] : https://getgb.io/

How to quit a long-running unit test?

Hi,

What is the key-binding to quit a long-running unit test and kill the background process?

Thanks

Please add a prefix to test-helper.el to avoid conflicts with 68 other packages

There exist at least 69 packages that contain a file named test-helper.el that also provides the feature test-helper.

This leads to issues for users who have at least two of these packages installed. It is unlikely that such a user would be able to run the tests of all of those packages. If the primary test file of one of those packages does (require 'test-helper), then it is undefined which of the various test-helper.el files gets loaded. Which it is, depends on the order of the load-path.

To avoid this conflicts, you should rename your test-helper.el to <your-package>-test-helper.el and adjust the feature accordingly.

Also don't forget to update the require form in your primary test file and/or update references to the library/feature elsewhere. Also, if your primary test file is named something like test.el, then please consider renaming that too (same for any other utility elisp files your repositoroy may contain).

Thanks!

PS: This issue is a bit generic because I had to open 69 issues.

subtest support

It would be nice if there was a way to suport testsuite subtest, I currently have this hack where if I detect the current line as "name": "name of test",

it will run the testname with "/name_of_test" appended to gotest, this hack look like this :

(defun my-gotest-maybe-ts-run()
    (interactive)
    (let ((testrunname)
          (gotest (cadr (go-test--get-current-test-info))))
      (save-excursion
        (goto-char (line-beginning-position))
        (re-search-forward "name:[[:blank:]]*\"\\([^\"]*\\)\"" (line-end-position) t))
      (setq testrunname (match-string-no-properties 1))
      (if testrunname
          (setq gotest (format "%s/%s" gotest (shell-quote-argument
                                               (replace-regexp-in-string " " "_" testrunname)))))
      (go-test--go-test (concat "-run " gotest "\\$ ."))))

this works relatively well but that's really depend if the user is on the "name" line and I wonder if this could make it smarter before submitting it.

perhaps the only way to know that properly is to do this with tree-sitter or see if lsp can help.

go-test-current-test should support benchmarks

This can be done by executing the following command (or similar) if go-test-current-test has been called inside a BenchmarkA function:

go test -run ^NOTHING -bench BenchmarkA$

go-test-current-test runs previous Test instead of current Example

Given the following Go file:

func Test1(t *testing.T) {

}

func Example1() {

}

go-test-current-test when executed inside Example1 currently runs Test1

go-test-current-file runs all tests in the current package

This is due to slightly wrong regex:

go test -run='TestA|TestB|'

while it should be

go test -run='TestA|TestB'

go-test-current-test doesn't work if the current test is part of a testify test suite

If point is in a test that's part of a testify test suite, go-test-current-test fails with an error:

$ go test -m TestSomeTestInASuite\$ .
flag provided but not defined: -m

After playing around with it, it seems to work just fine if I change -m to -testify.m:

$ go test -testify.m TestSomeTestInASuite\$ .

Although this testify issue suggests that the correct command would be:

$ go test -run TestThatCallsSuiteRun -testify.m TestSomeTestInASuite\$ .

Where TestThatCallsSuiteRun is the function that calls suite.Run() with your test suite struct type.

But it seems like at least for go 1.10 and the latest version of testify, it works with just -testify.m without -run.

go-test-current-test can not print fmt.Print content

My TestMain function is

func TestMain(m *testing.M) {
	fmt.Println("***********==========**************")
	m.Run()
}

When I run the test in the terminal it will display the Println content, but when I use go-test-current-test,
it will only display

go test -run TestFunction\$ .
ok 	0.003s

And I have no idea how to fix it.

go-test-current-test doesn't run Example function that is placed after Test function

The following code can be used to reproduce:

package main

import (
    "fmt"
    "testing"
)

func TestA(t *testing.T) {
    t.Logf("test")
}

func ExampleB() {
    fmt.Println("Example")
    // Output:
    // Example
}

Running go-test-current-file with the cursor inside ExampleB results in unable to find test error.