FAQ
Hi all,

I'm working as a Java developer, I'm fairly new in the Go world and having
a hard time to understand how to write tests properly.
In Java we usually mock every external dependency and it's pretty easy when
working with classes, autowiring dependencies etc.
I watched some talk/read articles about testing, they mostly suggest to
write stubs manually, without a framework, using interfaces in the code, or
define functions as variables and overwrite them in tests(but usually it's
not a good idea).
When we have an interface, then really not too hard to write a stub, but
when we using a function from an external package, then it's not that
straightforward.
in the latter case, a solution to create an interface, a type which
implement it and call the external function in production code and some
stub in test.
But this is really a good solution? Polluting our packages with this kind
of stuff makes the code noisy.
With mocking frameworks maybe harder to steup the test, but the production
code stays clean.

I checked some tests in the stdlib, e.g. for the JSON-RPC and ioutil
package and for some type they creating stubs, but mostly they are using
the real packages(json.NewDecoder etc).
As I learned, because of the lack of isolation these are not unit tests,
more like kind of integration tests.
Is this an approved approach for testing in Go?
So for example if I using json.Unmarshal function in a package, should I
hide it behind an internal interface/type and stub it or just use the real
method in tests too?

I know there's some similar topics, articles, but I can't find one which
compare the testing methods with other OO languages, like Java/C# etc.
I know that hard to test code usually means bad design, but as a newbie, a
little bit hard to catch these things.
As I mentioned, I'm trying to read the tests in the stdlib, but without the
whole process, seeing only the results, sometimes they are complicated.

Thanks,
Norbert

--
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

  • Egon at Oct 20, 2014 at 12:25 pm

    On Monday, 20 October 2014 14:43:43 UTC+3, Norbert Csibra wrote:
    Hi all,

    I'm working as a Java developer, I'm fairly new in the Go world and having
    a hard time to understand how to write tests properly.
    In Java we usually mock every external dependency and it's pretty easy
    when working with classes, autowiring dependencies etc.
    I watched some talk/read articles about testing, they mostly suggest to
    write stubs manually, without a framework, using interfaces in the code, or
    define functions as variables and overwrite them in tests(but usually it's
    not a good idea).
    When we have an interface, then really not too hard to write a stub, but
    when we using a function from an external package, then it's not that
    straightforward.
    in the latter case, a solution to create an interface, a type which
    implement it and call the external function in production code and some
    stub in test.
    But this is really a good solution? Polluting our packages with this kind
    of stuff makes the code noisy.
    With mocking frameworks maybe harder to steup the test, but the production
    code stays clean.

    I checked some tests in the stdlib, e.g. for the JSON-RPC and ioutil
    package and for some type they creating stubs, but mostly they are using
    the real packages(json.NewDecoder etc).
    As I learned, because of the lack of isolation these are not unit tests,
    more like kind of integration tests.
    Is this an approved approach for testing in Go?
    So for example if I using json.Unmarshal function in a package, should I
    hide it behind an internal interface/type and stub it or just use the real
    method in tests too?

    I know there's some similar topics, articles, but I can't find one which
    compare the testing methods with other OO languages, like Java/C# etc.
    I know that hard to test code usually means bad design, but as a newbie, a
    little bit hard to catch these things.
    As I mentioned, I'm trying to read the tests in the stdlib, but without
    the whole process, seeing only the results, sometimes they are complicated.
    The better question is, why do you want to write unit tests in the first
    place?
    What do you want to accomplish with it?
    Why do you want to isolate the tests from the environment where they are
    working?

    I suggest watching/reading:
    * http://www.carlopescio.com/2011/06/cut-red-wire.html
    * http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
    * http://www.rbcs-us.com/documents/Segue.pdf
    * http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
    * (also all the threads with counter arguments...)
    * and https://www.destroyallsoftware.com/talks/boundaries

    Try to figure out why you are doing what you are doing... if you figure
    that out, you'll find multiple solutions how to do things.

    + egon

    --
    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.
  • Norbert Csibra at Oct 20, 2014 at 2:16 pm
    Because we working in a TDD way at work and creating test based on the test
    pyramid concept and I find it quite useful.
    I read the DHH article earlier and some responses and watched all the
    hangout with Kent Beck, Martin Fowler and DHH and mostly I agree with the
    former guys, at least when working with Java, mainly because of the easy
    detection of the problems during development.
    I'm not thinking that the same things work well in Go, I want to figure
    that out.
    Mostly I see multiple solutions, I just not sure which is the
    correct("idiomatic") way in Go.
    On Monday, October 20, 2014 2:25:30 PM UTC+2, egon wrote:


    On Monday, 20 October 2014 14:43:43 UTC+3, Norbert Csibra wrote:

    Hi all,

    I'm working as a Java developer, I'm fairly new in the Go world and
    having a hard time to understand how to write tests properly.
    In Java we usually mock every external dependency and it's pretty easy
    when working with classes, autowiring dependencies etc.
    I watched some talk/read articles about testing, they mostly suggest to
    write stubs manually, without a framework, using interfaces in the code, or
    define functions as variables and overwrite them in tests(but usually it's
    not a good idea).
    When we have an interface, then really not too hard to write a stub, but
    when we using a function from an external package, then it's not that
    straightforward.
    in the latter case, a solution to create an interface, a type which
    implement it and call the external function in production code and some
    stub in test.
    But this is really a good solution? Polluting our packages with this kind
    of stuff makes the code noisy.
    With mocking frameworks maybe harder to steup the test, but the
    production code stays clean.

    I checked some tests in the stdlib, e.g. for the JSON-RPC and ioutil
    package and for some type they creating stubs, but mostly they are using
    the real packages(json.NewDecoder etc).
    As I learned, because of the lack of isolation these are not unit tests,
    more like kind of integration tests.
    Is this an approved approach for testing in Go?
    So for example if I using json.Unmarshal function in a package, should I
    hide it behind an internal interface/type and stub it or just use the real
    method in tests too?

    I know there's some similar topics, articles, but I can't find one which
    compare the testing methods with other OO languages, like Java/C# etc.
    I know that hard to test code usually means bad design, but as a newbie,
    a little bit hard to catch these things.
    As I mentioned, I'm trying to read the tests in the stdlib, but without
    the whole process, seeing only the results, sometimes they are complicated.
    The better question is, why do you want to write unit tests in the first
    place?
    What do you want to accomplish with it?
    Why do you want to isolate the tests from the environment where they are
    working?

    I suggest watching/reading:
    * http://www.carlopescio.com/2011/06/cut-red-wire.html
    * http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
    * http://www.rbcs-us.com/documents/Segue.pdf
    * http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
    * (also all the threads with counter arguments...)
    * and https://www.destroyallsoftware.com/talks/boundaries

    Try to figure out why you are doing what you are doing... if you figure
    that out, you'll find multiple solutions how to do things.

    + egon
    --
    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.
  • Egon at Oct 20, 2014 at 2:52 pm

    On Monday, 20 October 2014 17:16:04 UTC+3, Norbert Csibra wrote:
    Because we working in a TDD way at work and creating test based on the
    test pyramid concept and I find it quite useful.
    I read the DHH article earlier and some responses and watched all the
    hangout with Kent Beck, Martin Fowler and DHH and mostly I agree with the
    former guys, at least when working with Java, mainly because of the *easy
    detection of the problems during development*.
    Remember that... that is what you are trying to accomplish... don't let it
    out of your mind.
    You are not trying to write unit tests... unit tests are just one way to
    accomplish that. But, there are also generated tests, integration tests,
    BDD.

    Now what are the main reasons for having faking/stubbing/mocking?

    I'm not thinking that the same things work well in Go, I want to figure
    that out.
    Mostly I see multiple solutions, I just not sure which is the
    correct("idiomatic") way in Go.
    It depends... this is why I'm forcing you to reason about what and how are
    you testing. That way when a new thing comes along, you can figure out what
    to do.

    Write tests such that you have as little waste as possible, but still have
    the needed benefits.

    Think about this...

    How long does it take to find a bug that happens during integration test /
    unit test / asserts?
    How much of the application covers integration test / unit test / asserts?
    How much effort is it to write an integration test / unit test / asserts?
    What is the (running/development) cost of integration test / unit test /
    asserts?

    My general approach after determining the necessity of testing:

    Simple structs -> question whether tests are necessary at all, code usually
    gets exercised with other tests
    Functional code -> unit tests
    Hard to get right code, with lots of corner cases -> generated tests
    Easily describable model -> automatic model checking
    (http://golang.org/pkg/testing/quick/)
    Behavior code -> partition code as Gary Bernhardt shows and use integration
    tests,
        *with using mocks/stubs etc. if there's a reason. *
    * Use interfaces for the interacting pieces if it simplifies things**.*
    Have an oracle that knows the right answer -> cross validation.

    + egon

    On Monday, October 20, 2014 2:25:30 PM UTC+2, egon wrote:


    On Monday, 20 October 2014 14:43:43 UTC+3, Norbert Csibra wrote:

    Hi all,

    I'm working as a Java developer, I'm fairly new in the Go world and
    having a hard time to understand how to write tests properly.
    In Java we usually mock every external dependency and it's pretty easy
    when working with classes, autowiring dependencies etc.
    I watched some talk/read articles about testing, they mostly suggest to
    write stubs manually, without a framework, using interfaces in the code, or
    define functions as variables and overwrite them in tests(but usually it's
    not a good idea).
    When we have an interface, then really not too hard to write a stub, but
    when we using a function from an external package, then it's not that
    straightforward.
    in the latter case, a solution to create an interface, a type which
    implement it and call the external function in production code and some
    stub in test.
    But this is really a good solution? Polluting our packages with this
    kind of stuff makes the code noisy.
    With mocking frameworks maybe harder to steup the test, but the
    production code stays clean.

    I checked some tests in the stdlib, e.g. for the JSON-RPC and ioutil
    package and for some type they creating stubs, but mostly they are using
    the real packages(json.NewDecoder etc).
    As I learned, because of the lack of isolation these are not unit tests,
    more like kind of integration tests.
    Is this an approved approach for testing in Go?
    So for example if I using json.Unmarshal function in a package, should I
    hide it behind an internal interface/type and stub it or just use the real
    method in tests too?

    I know there's some similar topics, articles, but I can't find one which
    compare the testing methods with other OO languages, like Java/C# etc.
    I know that hard to test code usually means bad design, but as a newbie,
    a little bit hard to catch these things.
    As I mentioned, I'm trying to read the tests in the stdlib, but without
    the whole process, seeing only the results, sometimes they are complicated.
    The better question is, why do you want to write unit tests in the first
    place?
    What do you want to accomplish with it?
    Why do you want to isolate the tests from the environment where they are
    working?

    I suggest watching/reading:
    * http://www.carlopescio.com/2011/06/cut-red-wire.html
    * http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
    * http://www.rbcs-us.com/documents/Segue.pdf
    * http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
    * (also all the threads with counter arguments...)
    * and https://www.destroyallsoftware.com/talks/boundaries

    Try to figure out why you are doing what you are doing... if you figure
    that out, you'll find multiple solutions how to do things.

    + egon
    --
    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.
  • Norbert Csibra at Oct 21, 2014 at 3:48 pm
    Thanks, I need some time to process and understand correctly and integrate
    to my workflow, but I will try. :)
    On Monday, October 20, 2014 4:52:10 PM UTC+2, egon wrote:
    On Monday, 20 October 2014 17:16:04 UTC+3, Norbert Csibra wrote:

    Because we working in a TDD way at work and creating test based on the
    test pyramid concept and I find it quite useful.
    I read the DHH article earlier and some responses and watched all the
    hangout with Kent Beck, Martin Fowler and DHH and mostly I agree with the
    former guys, at least when working with Java, mainly because of the *easy
    detection of the problems during development*.
    Remember that... that is what you are trying to accomplish... don't let it
    out of your mind.
    You are not trying to write unit tests... unit tests are just one way to
    accomplish that. But, there are also generated tests, integration tests,
    BDD.

    Now what are the main reasons for having faking/stubbing/mocking?

    I'm not thinking that the same things work well in Go, I want to figure
    that out.
    Mostly I see multiple solutions, I just not sure which is the
    correct("idiomatic") way in Go.
    It depends... this is why I'm forcing you to reason about what and how are
    you testing. That way when a new thing comes along, you can figure out what
    to do.

    Write tests such that you have as little waste as possible, but still have
    the needed benefits.

    Think about this...

    How long does it take to find a bug that happens during integration test /
    unit test / asserts?
    How much of the application covers integration test / unit test / asserts?
    How much effort is it to write an integration test / unit test / asserts?
    What is the (running/development) cost of integration test / unit test /
    asserts?

    My general approach after determining the necessity of testing:

    Simple structs -> question whether tests are necessary at all, code
    usually gets exercised with other tests
    Functional code -> unit tests
    Hard to get right code, with lots of corner cases -> generated tests
    Easily describable model -> automatic model checking (
    http://golang.org/pkg/testing/quick/)
    Behavior code -> partition code as Gary Bernhardt shows and use
    integration tests,
    *with using mocks/stubs etc. if there's a reason. *
    * Use interfaces for the interacting pieces if it simplifies things**.*
    Have an oracle that knows the right answer -> cross validation.

    + egon

    On Monday, October 20, 2014 2:25:30 PM UTC+2, egon wrote:


    On Monday, 20 October 2014 14:43:43 UTC+3, Norbert Csibra wrote:

    Hi all,

    I'm working as a Java developer, I'm fairly new in the Go world and
    having a hard time to understand how to write tests properly.
    In Java we usually mock every external dependency and it's pretty easy
    when working with classes, autowiring dependencies etc.
    I watched some talk/read articles about testing, they mostly suggest to
    write stubs manually, without a framework, using interfaces in the code, or
    define functions as variables and overwrite them in tests(but usually it's
    not a good idea).
    When we have an interface, then really not too hard to write a stub,
    but when we using a function from an external package, then it's not that
    straightforward.
    in the latter case, a solution to create an interface, a type which
    implement it and call the external function in production code and some
    stub in test.
    But this is really a good solution? Polluting our packages with this
    kind of stuff makes the code noisy.
    With mocking frameworks maybe harder to steup the test, but the
    production code stays clean.

    I checked some tests in the stdlib, e.g. for the JSON-RPC and ioutil
    package and for some type they creating stubs, but mostly they are using
    the real packages(json.NewDecoder etc).
    As I learned, because of the lack of isolation these are not unit
    tests, more like kind of integration tests.
    Is this an approved approach for testing in Go?
    So for example if I using json.Unmarshal function in a package, should
    I hide it behind an internal interface/type and stub it or just use the
    real method in tests too?

    I know there's some similar topics, articles, but I can't find one
    which compare the testing methods with other OO languages, like Java/C# etc.
    I know that hard to test code usually means bad design, but as a
    newbie, a little bit hard to catch these things.
    As I mentioned, I'm trying to read the tests in the stdlib, but without
    the whole process, seeing only the results, sometimes they are complicated.
    The better question is, why do you want to write unit tests in the first
    place?
    What do you want to accomplish with it?
    Why do you want to isolate the tests from the environment where they are
    working?

    I suggest watching/reading:
    * http://www.carlopescio.com/2011/06/cut-red-wire.html
    * http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
    * http://www.rbcs-us.com/documents/Segue.pdf
    *
    http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
    * (also all the threads with counter arguments...)
    * and https://www.destroyallsoftware.com/talks/boundaries

    Try to figure out why you are doing what you are doing... if you figure
    that out, you'll find multiple solutions how to do things.

    + egon
    --
    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
postedOct 20, '14 at 11:43a
activeOct 21, '14 at 3:48p
posts5
users2
websitegolang.org

2 users in discussion

Norbert Csibra: 3 posts Egon: 2 posts

People

Translate

site design / logo © 2022 Grokbase