#go-nuts

/

      • ghost64 has quit
      • ghost64 joined the channel
      • streblo has quit
      • marxarelli|afk is now known as marxarelli
      • jubal has quit
      • streblo joined the channel
      • Wessie
        it's kinda annoying that you can miss a ctx.Done() receive because other channels in the select were ready as well
      • nika joined the channel
      • rngkll has quit
      • streblo has quit
      • Tv`
        Wessie: it's no different than that becoming ready an unobservably tiny moment later
      • select is designed to be fair, so it'll sort itself out
      • kingarmadillo joined the channel
      • Wessie
        it would be fine in most cases yeah, but there is some database mutation after one of mine, and I rather not have it do that when Done is ready, so I have a second select to make sure
      • vendan
        if you really care, put a non blocking receive right after the select as well
      • :)
      • Wessie
        but yes, it's a very tiny chance
      • nika has quit
      • vendan
        2 channels coming ready at once?
      • it's honestly insanely small chance
      • Wessie
        exactly
      • but that's not zero :)
      • vendan
        more significant is the "both were ready going in"
      • talking like nanoseconds though
      • I've done the testing
      • Wessie
        yeah both being ready when going in is possible too in this code path
      • vendan
        yeah, that's the one to care about
      • xkapastel joined the channel
      • danthemyth joined the channel
      • streblo joined the channel
      • Tv`
        you could short circuit the cancel before the big select
      • that way it's not in every branch
      • identical for the "both ready" case, different only on the day when you should really be buying a lotto ticket
      • Wessie
        it's only one channel and the done in this case, so I just have it behind the select since it's a single code path
      • rugt joined the channel
      • streblo has quit
      • Tv`
        ah
      • streblo joined the channel
      • danthemyth has quit
      • danthemyth joined the channel
      • rugt has quit
      • lluad has quit
      • andyhuzhill joined the channel
      • antsanto joined the channel
      • davr0s has quit
      • Siegfried joined the channel
      • kingarmadillo joined the channel
      • davr0s joined the channel
      • davr0s has quit
      • andyhuzhill has quit
      • andyhuzhill joined the channel
      • rugt joined the channel
      • lluad joined the channel
      • rugt has quit
      • jwynn6 joined the channel
      • shabius has quit
      • shabius joined the channel
      • hwm4rgs has quit
      • hwm4rgs joined the channel
      • howdoi joined the channel
      • veegee has quit
      • Anticlaus has quit
      • antsanto has quit
      • veegee joined the channel
      • ghostbar has quit
      • streblo has quit
      • eric_lagergren joined the channel
      • ttadc has quit
      • dozn has quit
      • shabius has quit
      • nyexpress joined the channel
      • shabius joined the channel
      • xSmurf joined the channel
      • hwm4rgs has quit
      • hwm4rgs joined the channel
      • marxarelli is now known as marxarelli|afk
      • Freman
        ... well there's something that doesn't happen often... I marked a merge request as LGTM and even approved it
      • antsanto joined the channel
      • shabius has quit
      • veegee has quit
      • vyrus001 joined the channel
      • nofoo1 joined the channel
      • shackra joined the channel
      • andlabs joined the channel
      • antsanto has quit
      • veegee joined the channel
      • hwm4rgs has quit
      • m3troX joined the channel
      • gsimondon joined the channel
      • hwm4rgs joined the channel
      • Siegfried joined the channel
      • jubal joined the channel
      • antsanto joined the channel
      • nika joined the channel
      • quite joined the channel
      • antsanto has quit
      • antsanto joined the channel
      • nika has quit
      • antsanto has quit
      • mschoch has quit
      • ganbold joined the channel
      • slimetrap has quit
      • fgau joined the channel
      • sixth joined the channel
      • nexdev9 has quit
      • Term1nal has quit
      • b0nn
        I don't have a strong grip on testing; I have a function that requires a pointer to an interface that I want to mock, but I can't get my head around doing that. Does anyone have a clear way for doing this?
      • safe joined the channel
      • bpalmer
        b0nn: if it's to an interface, you don't really have to 'mock' anything.
      • lluad
        Make a toy struct and member functions that implement that interface, and test with that.
      • bpalmer
        just make a new type that implements it
      • b0nn
        ok, the thing I want to mock is github.com/scottdware/go-junos
      • bpalmer
        what type?
      • b0nn
        What I am trying to do is test the function that I have created that uses a connection to a juniper router provided by github.com/scottdware/go-junos (Junos)
      • I want to test the function, but not have it make a call to a router
      • so, this type type Junos struct{}
      • bpalmer
        that's a bit less friendly, because it's not an interface. (It's also not an empty struct)
      • b0nn
        yeah, it's been a bit of a struggle to get my mind around what I am trying to do
      • bpalmer
        b0nn: but eyeballing it, everythig is based on an interface netconf.Transport which is used for the sending and receiving.
      • HardlySeen has quit
      • If you create a FakeTransport, you can then create a new netconf.Session and use that to make a new junos.Junos
      • antsanto joined the channel
      • saml_ joined the channel
      • and you'll never need to open a network connection.
      • b0nn
        ok, can you expand on that a bit, I'm not 100% across what you're trying to explain
      • HardlySeen joined the channel
      • obiwan90 has quit
      • antsanto has quit
      • bpalmer
        b0nn: Junos is a struct with a *netconf.Session, a string, int, []RoutingEngine, and a time.Duration. (A routing engine is a pair of strings)
      • b0nn: so the only thing that complicates your ability to make up one of these for your test is the *netconf.Session
      • apiarian joined the channel
      • Well, maybe it'd work if you left that session nil.
      • But assume not. How hard is it to make a netconf.Session?
      • veegee has quit
      • A Session is a bunch of methods that use a Transport for input and output.
      • b0nn
      • bpalmer
        So if you control the Transport, you control input and output -- which is what you want in order to control the test.
      • brandly joined the channel
      • and thankfully Transport is an interface, so you can do the toy struct and methods as lluad suggested.
      • We're cheating a little bit by peeking at the classes, but I find that often helps when testing.
      • peeking at the implementations, that is, rather than relying exclusively on the documentation.
      • maerwald joined the channel
      • mschoch joined the channel
      • b0nn
        ok, so if I am hearing you (and lluad) correctly I need to create an implementation of the Transport interface that (essentially) does nothing, and have a Session use it (somehow) and then use that session in my fakeJunos?
      • Shawn has quit
      • bpalmer
        sure.
      • b0nn
        heh, I'm new to this so it's a lot of black magic
      • lupine
        another option is to stand up a http server that the client connects to
      • it's not *totally* awful
      • Tv`
        sounds like it'd have to emulate a Juniper either way, which doesn't sound like fun