FAQ
Hi,
I deal a lot with code that has a lot of network or db dependencies. I
would like to test it properly without need of relying on full env (at
least in unit test). My idea is to injection of interfaces. But then, I
will have quite a bit of them: for db, messaging system, tcp, etc. Most of
the case I would have only 2 implementations: real one and fake for test.
From your experience, does my approach makes sense? What are proc and cons?

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

Search Discussions

  • Volker Dobler at Jan 19, 2015 at 10:14 am

    Am Montag, 19. Januar 2015 09:32:26 UTC+1 schrieb Sławosz Sławiński:
    Hi,
    I deal a lot with code that has a lot of network or db dependencies. I
    would like to test it properly without need of relying on full env (at
    least in unit test). My idea is to injection of interfaces. But then, I
    will have quite a bit of them: for db, messaging system, tcp, etc. Most of
    the case I would have only 2 implementations: real one and fake for test.
    From your experience, does my approach makes sense? What are proc and cons?
    I like this approach: I often start with just the real implementation and
    once
    it becomes cumbersome to test or worth abstracting I refactor to an
    interface,
    add a "fake" implementation for testing, etc.

    V.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Paweł Borkowski at Jan 20, 2015 at 2:58 pm
    Another approaches:

    1) partial mocking:

    func Foo() {
       foo()
    }

    var foo = func() {
       ...
    }

    Now, you can substitute the foo function with your fake one. I like this
    approach for testing inside the package.

    2) fake environment:
    Starting, querying and stopping http server is sth about 10-30ms (of
    course, YMMV)
    Setting up a SQL schema, performing simple queries on small data set and
    tearing everything down has similar running time.
    Having a ready-to-use http server that does (almost) the same things as
    your production code = priceless.

    I have large part of my tests doing exactly that: starting a http server,
    starting a DB, setting up the schema, putting some test data inside and the
    running 1-3 HTTP queries. Whole test takes ~100ms.

    W dniu poniedziałek, 19 stycznia 2015 09:32:26 UTC+1 użytkownik Sławosz
    Sławiński napisał:
    Hi,
    I deal a lot with code that has a lot of network or db dependencies. I
    would like to test it properly without need of relying on full env (at
    least in unit test). My idea is to injection of interfaces. But then, I
    will have quite a bit of them: for db, messaging system, tcp, etc. Most of
    the case I would have only 2 implementations: real one and fake for test.
    From your experience, does my approach makes sense? What are proc and cons?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • DV at Jan 20, 2015 at 9:17 pm
    Step 1. Define an interface
    typer Barer interface {
        DoBar()
    }

    Step 2. Things happen in functions. Here's a function that does something.
    "Barer" can be the real barer, or a fake barer, function doesn't know/care

    func foo(Barer bar){
        bar.DoBar()
    }

    3. Step 3 is self-explanatory - inject a real Barer, or a fake Barer,
    which-ever you wish


    There is *another* approach, favored by a lot of people, which is:

    var f = func foo(){
    ...
    }

    and then they redefine "f" in tests. I hate that. It feels hacky, an
    "un-Go", to me at least.
    On Monday, January 19, 2015 at 1:32:26 AM UTC-7, Sławosz Sławiński wrote:

    Hi,
    I deal a lot with code that has a lot of network or db dependencies. I
    would like to test it properly without need of relying on full env (at
    least in unit test). My idea is to injection of interfaces. But then, I
    will have quite a bit of them: for db, messaging system, tcp, etc. Most of
    the case I would have only 2 implementations: real one and fake for test.
    From your experience, does my approach makes sense? What are proc and cons?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 19, '15 at 8:32a
activeJan 20, '15 at 9:17p
posts4
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase