FAQ
Hey guys, I've published a blog about mocking/stubbing/testing in golang.
  Love to get your thoughts:

http://blog.getsocialize.com/2013/getting-a-handle-on-testing-and-mocking-in-golang

--
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/groups/opt_out.

Search Discussions

  • Jan Mercl at Oct 2, 2013 at 8:31 am

    On Wed, Oct 2, 2013 at 1:07 AM, Isaac Mosquera wrote:
    Hey guys, I've published a blog about mocking/stubbing/testing in golang.
    Love to get your thoughts:
    Did I understood correctly that the mocking approach to testing means
    that actually tested are "mocked" functions, which are not used
    outside testing and their counterpart functions, that are actually run
    outside testing, are not tested?

    -j

    --
    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/groups/opt_out.
  • Chris dollin at Oct 2, 2013 at 10:01 am

    On 2 October 2013 09:31, Jan Mercl wrote:
    On Wed, Oct 2, 2013 at 1:07 AM, Isaac Mosquera wrote:
    Hey guys, I've published a blog about mocking/stubbing/testing in golang.
    Love to get your thoughts:
    Did I understood correctly that the mocking approach to testing means
    that actually tested are "mocked" functions, which are not used
    outside testing and their counterpart functions, that are actually run
    outside testing, are not tested?
    No.

    You mock the things you are /not/ testing to provide setup and
    access for checking that what you're testing does what it says
    on its tin.

    (Whether having a mocking framework, or whether emphasis
      on mocking is a good thing or not, I am not addressing.)

    Chris

    --
    Chris "using Turtle doesn't make me a turtle." Dollin

    --
    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/groups/opt_out.
  • Jan Mercl at Oct 2, 2013 at 10:18 am

    On Wed, Oct 2, 2013 at 12:01 PM, chris dollin wrote:
    On 2 October 2013 09:31, Jan Mercl wrote:

    Did I understood correctly that the mocking approach to testing means
    that actually tested are "mocked" functions, which are not used
    outside testing and their counterpart functions, that are actually run
    outside testing, are not tested?
    No.

    You mock the things you are /not/ testing to provide setup and
    access for checking that what you're testing does what it says
    on its tin.
    Thanks! Then, what if a mocked function runs okay (it's the "not
    tested" thing), but the "real" one would hit a bug which only the
    _tested_ usage pattern triggers?

    -j

    --
    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/groups/opt_out.
  • Chris dollin at Oct 2, 2013 at 10:40 am

    On 2 October 2013 11:18, Jan Mercl wrote:
    On Wed, Oct 2, 2013 at 12:01 PM, chris dollin wrote:
    On 2 October 2013 09:31, Jan Mercl wrote:

    Did I understood correctly that the mocking approach to testing means
    that actually tested are "mocked" functions, which are not used
    outside testing and their counterpart functions, that are actually run
    outside testing, are not tested?
    No.

    You mock the things you are /not/ testing to provide setup and
    access for checking that what you're testing does what it says
    on its tin.
    Thanks! Then, what if a mocked function runs okay (it's the "not
    tested" thing), but the "real" one would hit a bug which only the
    _tested_ usage pattern triggers?
    Then that test will not detect that problem; it would have to be
    caught by "earlier" tests (ie those on the thing that was mocked)
    or "later" tests (integration tests that use the real code not the
    test framework).

    If you're mocking thing X to test thing Y, then you're not (at this
    time) testing X, so it's reasonable to not find a problem in X.

    Chris

    --
    Chris "allusive" Dollin

    --
    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/groups/opt_out.
  • Jan Mercl at Oct 2, 2013 at 10:54 am

    On Wed, Oct 2, 2013 at 12:40 PM, chris dollin wrote:
    If you're mocking thing X to test thing Y, then you're not (at this
    time) testing X, so it's reasonable to not find a problem in X.
    That's a pity. "Total" testing (with binary answer bugs or bugs-free)
    is equal to the halting problem, so we can only approximate by testing
    only some reasonable cases/scenarios. Mocking obviously loses
    additional opportunities to trigger bugs not seen by other tests
    because of some usage difference.

    -j

    --
    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/groups/opt_out.
  • Chris dollin at Oct 2, 2013 at 11:09 am

    On 2 October 2013 11:53, Jan Mercl wrote:
    On Wed, Oct 2, 2013 at 12:40 PM, chris dollin wrote:
    If you're mocking thing X to test thing Y, then you're not (at this
    time) testing X, so it's reasonable to not find a problem in X.
    That's a pity. "Total" testing (with binary answer bugs or bugs-free)
    is equal to the halting problem, so we can only approximate by testing
    only some reasonable cases/scenarios. Mocking obviously loses
    additional opportunities to trigger bugs not seen by other tests
    because of some usage difference.
    You mock in the cases where not mocking is too painful.

    It's trade-offs all the way down.

    Chris

    --
    Chris "allusive" Dollin

    --
    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/groups/opt_out.
  • Alexei Sholik at Oct 2, 2013 at 11:08 am

    Did I understood correctly that the mocking approach to testing means
    that actually tested are "mocked" functions, which are not used
    outside testing and their counterpart functions, that are actually run
    outside testing, are not tested?

    Haha. Jan is mocking the mocking. Or is it a mocked mocking?

    On Wed, Oct 2, 2013 at 11:31 AM, Jan Mercl wrote:
    On Wed, Oct 2, 2013 at 1:07 AM, Isaac Mosquera wrote:
    Hey guys, I've published a blog about mocking/stubbing/testing in golang.
    Love to get your thoughts:
    Did I understood correctly that the mocking approach to testing means
    that actually tested are "mocked" functions, which are not used
    outside testing and their counterpart functions, that are actually run
    outside testing, are not tested?

    -j

    --
    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/groups/opt_out.


    --
    Best regards
    Alexei Sholik

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 1, '13 at 11:07p
activeOct 2, '13 at 11:09a
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase