Provide hooks for testability
Related to this issue: https://github.com/mitchellh/packer/issues/451
This is working really well for me. I'm using the "library"-able part of the project which I hope will allow me to create a WinRM communicator for packer.
However, I'm finding it very difficult to design tests with masterzen/winrm underneath.
Do you have any tips or are you are open to contributions that along the lines of net/httptest?
Both of these cool Packer-oriented projects could benefit.
- https://github.com/dylanmei/packer-communicator-winrm
- https://github.com/justinclayton/packer-builder-vsphere
Hi I'm completely open to add a testing system. I just need to think about how to do it, I'm also open to contributions :-) Thanks for your interest in this project!
Here's an article that explains using httptest: https://willnorris.com/2013/08/testing-in-go-github
In our context with WinRM a test for a theoretical "Directory Listing Class" might look like:
package main
import (
"masterzen/winrm"
"masterzen/winrmtest"
"testing"
"io"
)
func Test_lister_should_list_the_temp_directory(t *testing.T) {
h := winrmtest.NewHost()
defer h.Close()
h.HandleCommand("dir C:\\Temp", func(out io.Writer) (exitCode int) {
out.Write(byte("test"))
exitCode = 0
return
})
lister := NewLister(h.HostURL)
temp, err := lister.ListTemp()
if err != nil {
t.Error(...)
}
if temp != "test" {
t.Error(...)
}
// and so on...
}
Forgive my poor pseudo-code! :) What do you think?
Your example looks perfect.
So if I understood correctly your idea, you'd use the real winrm client implementation and just implement a 'mock' winrm server (presumably based on httptest) in winrmtest that returns the content of the correct handler func as winrm responses, is that correct?
So the way you hook the test system to your running code is just the test url that points to the winrm test fake server. That's a nice solution because it doesn't involve any change to the winrm library implementation. I like that :)
I have a bit of spare time in the next couple of days, so if you haven't started working on this feature yet, I'd try to come up with something (I'll keep this issue posted with my findings).
Yes, that is the approach I am taking. I do have something almost usable for a simple case like the example above. I can push it up within 24 hours. :)
@dylanmei it's terrific! Ship it when you think it's ready, then we'll see how we can build on top of it for more features.
Great, I was able to get something working end-to-end.
- The experiement so far here: winrmtest
- I've started using it here: packer-communicator-winrm
@dylanmei, that looks good to me.
There's a few things we should do/add:
- stdin support
- dynamic ids, so that we can support several shell/commands in parallel (this is quite easy to add, since it looks like you have all the things in place)
- use more windows-like SOAP response
- streaming stdout support (it might not be necessary though)
I'll try to send you some PR during the next week-end to fix some of those issues.
Do you have plans to merge this here or do you prefer to have it in its own project/repo?