nathany / looper Goto Github PK

Not that it's slow, but when I make a simple change, it runs the tests twice. How does software even work?

go test ./suite_test.go file_test.go
2013/04/21 12:47:30 exit status 1
named files must all be in one directory; have ./ and 

Note the go test line above.

The go test line generated doesn't include production files. If the tests and production code are in the same package (eg. package main) it doesn't work. It needs an import statement (black box testing).

This does bring up the larger issue of whether GAT should only be compiling a subset of files, as mentioned on the Trello board.

Ideally I think it would compile an entire package but only run the tests for a particular file. Go 1.0.3 supports -test.run pattern but not limiting to specific files.

However, with modern Go versions, vendoring is on by default.

I am not sure if this has been discussed somewhere but if so I apologize.

My suggestion is just a switch "-make" or "-use-make" to tell looper to use a makefile if one is available possibly recursively for each directory.

If you agree that it is sound or have another suggestion I am willing to give it a shot at implementing it.

Raising a new issue for this, because #6 seems to happen because of Spotlight and I'm experiencing the same problem on Ubuntu 14.04.

I have two files: main.go and main_test.go, as well as a LICENSE and README.md file and a .git directory. Originally I thought my tests ran twice because Vim saves a swap file (filename~) but it turns out I have that option disabled.

This is the output I get from saving files with Vim:

$ looper --debug
Looper 0.2.3 is watching your files
Type help for help.

Debug mode enabled.

Watching path ./
Detected new file .//main.gz~
Detected new file .//main.go
Detected file modification .//main.go
go test ./.
ok      _/home/tobias/projects/chaps    0.002s
PASS (0.46 seconds)
go test ./.
ok      _/home/tobias/projects/chaps    0.002s
PASS (0.49 seconds)

This is the output I get from saving files with Gedit (tests only run once):

$ looper --debug
Looper 0.2.3 is watching your files
Type help for help.

Debug mode enabled.

Watching path ./
Detected new file .//.goutputstream-AAL7HX
Detected file modification .//.goutputstream-AAL7HX
Detected new file .//main.go~
Detected new file .//main.go
go test ./.
ok      _/home/tobias/projects/chaps    0.004s
PASS (0.51 seconds)

This is the output I get from saving files with nano:

$ looper --debug
Looper 0.2.3 is watching your files
Type help for help.

Debug mode enabled.

Watching path ./
Detected file modification .//main.go
Detected file modification .//main.go
go test ./.
ok      _/home/tobias/projects/chaps    0.005s
PASS (0.45 seconds)
go test ./.
ok      _/home/tobias/projects/chaps    0.002s
PASS (0.45 seconds)

In Go 1.6 the GO15VENDOREXPERIMENT environment variable is internally set to 1. But the code checks explicitly for the variable.

Aside from the detection, there is also the watching of the vendor directory tree. I think we can ignore this directory if the vendoring experiment is enabled. This reduces the open file count which is a good thing for macOS.

Any thoughts? No problem to prepare a PR.

The Go community seems to have settled on Godep as the dependency management tool of choice - it would make sense for looper to support it.

The presence of a Godeps folder on the directory from where looper / go test is normally run is a flag to run godep go test instead.

Eg local OS notifications in macOS, and similar for Linux/Windows.

Maybe could use terminal-notifier: https://github.com/julienXX/terminal-notifier

It seems looper is opening more files than a default Mac setup likes. Perhaps we should consider increasing the open file limit as, for example, is done in go-ipfs: https://github.com/ipfs/go-ipfs/blob/a933b288b3cbe506067e45a1da34dd6559dc417b/cmd/ipfs/ulimit.go

However, weirdly enough ulimit -n 1024 does not seem to solve the issue.

$ looper
Looper 0.3.3 is watching your files
Type help for help.

2017/01/17 10:22:21 Error watching:  vendor/golang.org/x/sys/unix too many open files
2017/01/17 10:22:21 Error watching:  vendor/golang.org/x/sys/windows open vendor/golang.org/x/sys/windows: too many open files
2017/01/17 10:22:21 Error watching:  vendor/golang.org/x/sys/windows/registry too many open files
[...]
Watching path ./
Watching path links
Watching path persistence
Watching path redirect
Watching path testing
Watching path testing/assert
Watching path testing/request
Watching path vendor
Watching path vendor/github.com
[...]
go test ./links
2017/01/17 10:23:24 open /dev/null: too many open files
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x4063a16]

goroutine 1 [running]:
panic(0x40f65a0, 0xc42000c0c0)
        /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/panic.go:500 +0x1a1
github.com/nathany/looper/gat.Run.goTest(0x0, 0x0, 0xc42004bd28, 0x1, 0x1)
        /Users/drbob/gocode/src/github.com/nathany/looper/gat/run.go:60 +0x206
github.com/nathany/looper/gat.Run.RunOnChange(0x0, 0x0, 0xc42027cd20, 0x13)
        /Users/drbob/gocode/src/github.com/nathany/looper/gat/run.go:31 +0xf4
github.com/nathany/looper/gat.(*Run).RunOnChange(0xc42000c760, 0xc42027cd20, 0x13)
        <autogenerated>:2 +0x6f
main.EventLoop(0x418eae0, 0xc42000c760, 0xc42000c700)
        /Users/drbob/gocode/src/github.com/nathany/looper/looper.go:29 +0x1a7
main.main()
        /Users/drbob/gocode/src/github.com/nathany/looper/looper.go:58 +0x175

Initially just installing Go in a VM to get it working and figure out the installation command and testing.

Then setup CI with http://www.appveyor.com/ to run PowerShell or a batch script:

https://twitter.com/appveyor/status/374213356657197058

The go command ignores directories that start with _. godep uses this to hide vendored code (under Godeps/_workspace). Given that tests under _workspace won't be run anyway, there's no reason to watch them.

Sample output, to illustrate:

Watching path ./
Watching path Godeps
Watching path Godeps/_workspace
Watching path Godeps/_workspace/src
Watching path Godeps/_workspace/src/github.com
Watching path Godeps/_workspace/src/github.com/gorilla
Watching path Godeps/_workspace/src/github.com/gorilla/context
Watching path Godeps/_workspace/src/github.com/gorilla/mux
Watching path [redacted]

go test ./...
ok      [redacted]  0.019s
PASS (0.71 seconds)

Some way of skipping folders such as "vendor" when executing a full test run, with a way to run those tests too (editing those files, for sure should).

go test $(go list ./... | grep -v '/vendor/')

https://groups.google.com/d/msg/golang-dev/74zjMON9glU/RI8lvzMAFacJ

ref: golang/go#11659 (comment)

Output:

$ go version
go version go1.12.1 darwin/amd64

$ go get -u github.com/nathany/looper
go: finding github.com/nathany/looper v0.2.3
go: downloading github.com/nathany/looper v0.2.3
go: extracting github.com/nathany/looper v0.2.3
go: finding github.com/bobappleyard/readline latest
go: finding github.com/gophertown/looper/gat latest
go: finding github.com/koyachi/go-term-ansicolor/ansicolor latest
go: finding github.com/koyachi/go-term-ansicolor latest
go: downloading github.com/koyachi/go-term-ansicolor v0.0.0-20130114081603-6f81280f9360
go: extracting github.com/koyachi/go-term-ansicolor v0.0.0-20130114081603-6f81280f9360
go: downloading github.com/bobappleyard/readline v0.0.0-20150707195538-7e300e02d38e
go: extracting github.com/bobappleyard/readline v0.0.0-20150707195538-7e300e02d38e
go: finding github.com/gophertown/looper v0.2.3
go: downloading github.com/gophertown/looper v0.2.3
go: extracting github.com/gophertown/looper v0.2.3
build github.com/nathany/looper: cannot load github.com/gophertown/fsnotify: cannot find module providing package github.com/gophertown/fsnotify

I have a few tests in my suite that take a long time to complete. These are skipped when I pass the -short flag. How do I pass this flag with Looper?

Is it possible to have tests run with -cover (if package is installed)?

An event (not sure which) triggered the following:

Watching path .git/hooks
Watching path .git/info
Watching path .git/logs
Watching path .git/objects
Watching path .git/refs
Watching path .git/objects/f5
Watching path .git/objects/5a
Watching path .git/objects/b4

This was an existing git repository, so the .git folder was not created. Using OS X (kqueue).

Seems like there may be a regression in the recent changes. Though it's not obvious to me what happened yet.

If atomic saves is on in Sublime Text 3, and when saving a file that has no counterpart test, Looper logs an error like this:

2013/05/16 15:09:37 stat gat/.subl16.tmp: no such file or directory

Not a real issue, maybe just don't log it.

Is it possible to do it as it stands now? It would be very neat to just be able to go something like this:

looper -bench

or maybe

looper -args="-bench .pattern."

Would be great to (optionally) run looper with the --race flag. Goroutines are a huge part of Go, which usually means those who use them (should) check for race conditions while testing.

This is a late-breaking reply to this golang-nuts thread. Autotest tools in Ruby, namely Ryan Davis' autotest (part of the ZenTest ruby gem), have sorted out an effective policy for continually running tests. Here's an autotest introduction article that covers its behavior. Other similar tools, esp. in the Ruby world, have also adopted this approach, which I'll summarize as:

1. At start, run all tests.
2. Watch the filesystem for changed files.
3. Run tests relevant to changed files.
4. If at any point there are failures, those tests are re-run on file change events until everything passes.
5. Once all tests are fixed, return to step 1 and run all tests.

The goal is not "efficiency" per se, but rather a workflow that keeps the focus on in-flight changes. For example, a change to existing code might well (temporarily) break functionality and tests across an entire project. The policy above allows the developer some breathing room to first get a change's "local" tests under control before unleashing the whole project's test suite.

Hoping the essentials end up in the go tool itself as a --watch flag:
http://golang.org/s/go13fsnotify