NATS mock

[Milos Gajdos]

Hi all,

does anyone have any NATS mock implementation in Go ?

I'm using natsq for one of my projects and I'm trying to figure out how to test it now, but I haven't found any natsq mocks I could use.

Anyone knows of any ? Possibly, any one has any hints on how to go about this ?

Thanks

M.

[Derek Collison]

You can embed the gnatsd server into your tests, so I do not think you need to have mocks at all..

import "github.com/nats-io/gnatsd/server"

s := server.New(opts)

go s.Start()

defer s.Shutdown()

--
You received this message because you are subscribed to the Google Groups "nats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to natsio+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Milos Gajdos]

Yeah that's what I tried to do actually before I came to ask here.

Actually the exact code I tried was something like this:

https://gist.github.com/milosgajdos83/4d3e6bd6ed62744ea27e

For some reason client always fails to establish connection - panic on line 40 always fires - that makes me assume the queue does start, but client can't connect with tdefault options ie localhost:4222

M.

[Derek Collison]

Looks reasonable. FYI you could just use gnatsd RunServer or RunDefaultServer from the test directory.. That way you don't have to dupe that code..

s := runDefaultServer()

Also, for client don't take & of nats.DefaultOptions, make a copy by opts := nats.DefaultOptions. As last resort without me trying to run the code, is something else running on 4222?

[Milos Gajdos]

Hi,

thanks for the hints.

So, unless RunServer is exported ie. inside non _test.go source file I can't reuse it without copy-pasting the code into my tests :-)

Speaking of RunServer() func, It might be worth it to make it first-class citizen of the server package ? (Happy to open a PR)

Anyways, I tried your suggestions to no avail (I've updated the original gist with RunServer() attempt). I have also checked if anything is running on port 4222 indeed.

Strange. I'm sure I'm missing something fundamental, but I've no idea what :-)

[Derek Collison]

Use this with your test options..

test.RunServer(opts *server.Options) *server.Server

Send me a smaller self contained file and I will take a look.. Or I can create one a bit later on. We will get you fixed up..

[Milos Gajdos]

Right, I overlooked that test package includes RunTest implementation. Awesome.

I've modified the original gist with a self-contained super simple test with which I started playing around at the beginning

M.

[Derek Collison]

Does it still fail?

[Milos Gajdos]

Yep:

panic: nats: No servers available for connection

goroutine 1 [running]:

github.com/milosgajdos83/taurus/queue.TestMain(0xc2080486e0)

/Users/milosgajdos/go/src/github.com/milosgajdos83/taurus/queue/queue_test.go:26 +0x107

main.main()

github.com/milosgajdos83/taurus/queue/_test/_testmain.go:48 +0x1d1

[Derek Collison]

DefaultOptions does not have a proper setup, that was my fault not picking that up at first..

This works in your gist..

url := fmt.Sprintf("nats://%s:%d", TestOptions.Host, TestOptions.Port)

conn, err := nats.Connect(url)

[Milos Gajdos]

BINGO! :-)

Thanks a lot! I kind believe I missed that. Uh.

Fantastic!

M.

[Alexander Staubo]

Replying to an old message:

On Thursday, 23 July 2015 15:39:34 UTC-4, derek wrote:

You can embed the gnatsd server into your tests, so I do not think you need to have mocks at all..

I disagree with this assessment. When I have code that interacts with NATS, my goal is to test how it interacts with the NATS client, not with NATS proper. This allows me to test a *much* smaller surface area and also test aspects of testing that cannot be easily done/provoked without mocking, such as testing that my client closes its connection or handles a sudden error. (I shouldn't have to, say, manipulate the process's file descriptors in order to simulate a flaky network, for example.)

IMHO, as a principle, every Go library should expose only interfaces for its primary "objects". Obviously, that's a bit late in this case. But interfaces could be provided for existing structs, at least.