Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As the title says - I was on a long plane trip, so I figured I'd try and spend my time implementing tests. Note that they launch the Honeytrap binary, since getting it to work with
honeytrap.New()
was too much of a pain in the ass - most importantly, it seems impossible to tell the Honeytrap goroutine to shut down, even after messing with server/honeytrap.go.Anyways, I developed some quick general tests (test that it starts with a dummy config, --help, the various --list), and service-specific tests for HTTP and Redis (http.Client/net.Dial + nmap checks). Before proceeding to write more tests, I'd like to know what you think of the overall test setup and what changes you suggest.
I'd also like ideas on how to test events (eg. "test that when you make a valid http request, an event is sent"). I thought of the following:
[filter.console] type="console"
), and have the test application read that. This seems to be outright impossible, given how the Honeytrap binary is launched - you can connect stdout to an os.File, not a custom io.Writer, which prevents us from reading stdout directly; and reading it from an actual file seems impractical.http := services.HTTP(options); http.Handle(...)
) and pass it a mock net.Conn. This is in my opinion the most interesting idea, but I'm afraid it would make tests depend too much on the implementation details (SetChannel, pass a TOML config, essentially make a second implementation of findService, ...) which are instead hidden when launching a process.Depends on #411, which I discovered while writing the tests; fixes #239.