FAQ
I have an interface in package “foo”. The compiler is making sure my
struct in package “bar” implements the interface, but I’d also like to have
a standard set of test code in “foo” can that be used by any implementer to
more fully test the behavior of functions. The test code would live in
“foo”, but would be called by tests is “bar” (or “baz”, next
implementation, ...). I can’t seem to do this if the standard tests in
“foo” are in files named "_test.go". Other file naming schemes do work,
but I wondered if there was some way for this code to live in normal
"_test.go" files while still being importable by another package’s tests.


Or... maybe this interface testing approach is more generally flawed?





Thanks,

Jim

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

  • Chris Kastorff at Dec 9, 2015 at 4:11 pm
    I've run into this problem several times, and although ugly, I've found
    this works:

         library // contains interface definition, no tests
         library/tests // contains helpers for testing the implementations
    generically, as well as wrappers importing backend/* and passing them to
    the helpers to test generic behavior
         library/backend/a // contains only a-specific tests, does not import
    library/tests
         library/backend/b // contains only b-specific tests, does not import
    library/tests
         ...

    For a concrete example, see
    https://github.com/encryptio/slime/tree/master/lib/store - storetests
    contains generic tests, and cache, multi, storedir, and storehttp contain
    implementations of store.Store.
    On Tue, Dec 1, 2015 at 10:50 AM, wrote:

    I have an interface in package “foo”. The compiler is making sure my
    struct in package “bar” implements the interface, but I’d also like to have
    a standard set of test code in “foo” can that be used by any implementer to
    more fully test the behavior of functions. The test code would live in
    “foo”, but would be called by tests is “bar” (or “baz”, next
    implementation, ...). I can’t seem to do this if the standard tests in
    “foo” are in files named "_test.go". Other file naming schemes do work,
    but I wondered if there was some way for this code to live in normal
    "_test.go" files while still being importable by another package’s tests.


    Or... maybe this interface testing approach is more generally flawed?





    Thanks,

    Jim

    --
    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.
    --
    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.
  • Kalafut at Dec 10, 2015 at 4:00 pm
    Thanks. This layout is similar to what I ended up doing.

    Regards,
    Jim
    On Tuesday, December 1, 2015 at 10:51:33 AM UTC-8, kal...@gmail.com wrote:

    I have an interface in package “foo”. The compiler is making sure my
    struct in package “bar” implements the interface, but I’d also like to have
    a standard set of test code in “foo” can that be used by any implementer to
    more fully test the behavior of functions. The test code would live in
    “foo”, but would be called by tests is “bar” (or “baz”, next
    implementation, ...). I can’t seem to do this if the standard tests in
    “foo” are in files named "_test.go". Other file naming schemes do work,
    but I wondered if there was some way for this code to live in normal
    "_test.go" files while still being importable by another package’s tests.


    Or... maybe this interface testing approach is more generally flawed?





    Thanks,

    Jim
    --
    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
postedDec 1, '15 at 6:51p
activeDec 10, '15 at 4:00p
posts3
users2
websitegolang.org

2 users in discussion

Kalafut: 2 posts Chris Kastorff: 1 post

People

Translate

site design / logo © 2021 Grokbase