FAQ
hi all, i've just thought to share this little patch i use to hack on the
before/after methods in testing.go. cheers. dorival

*init_test.go:*
package mypkg
import "testing"
func init() {
testing.MyBefore = func() {
/* start here */
}
testing.MyAfter = func() {
/* stop here */
}
}

*testing.go.diff
*
118a119,121
MyBefore = func() {}
MyAfter = func() {} 427a431
MyBefore() 456a461
MyAfter()
--

Search Discussions

  • Peter S at Oct 19, 2012 at 3:54 am
    Thanks for sharing this. It is not clear which version the diff is
    applicable to, so it would be nice if you could include the version
    identifier, either using 'hg id' or the VERSION file in the source package.
    (Also, the unified format for diff is preferable as it can be applied even
    if the line numbers have shifted due to unrelated changes.)

    It would also be nice if you could share some more explanation about the
    motivation, why you chose this approach, and what scenarios it is intended
    to be applicable to. It appears to me that this will cause issues when
    testing two or more packages, because they could potentially overwrite each
    others' Before/After functions in initialization, and the functions set in
    one package would remain set when testing other packages, which I am
    guessing is not desirable in general. Also, as a single package can
    encompass a wide range of functionality, I'm not sure if having common
    Before and After functions for all tests in a package is good practice in
    general (although it may be suit your specific situation).

    As an alternative approach, I'd suggest you consider using table-driven
    tests: http://code.google.com/p/go-wiki/wiki/TableDrivenTests . With
    table-driven tests, a single function can be used to perform tests for many
    cases in a loop. "Before" and "After" operations that should be executed
    for each test case can simply be written in the loop surrounding the actual
    test case invocation code. And of course it has the big advantage that
    people can compile/test your code with an unmodified Go distribution.

    Peter


    On Fri, Oct 19, 2012 at 7:01 AM, Dorival Pedroso
    wrote:
    hi all, i've just thought to share this little patch i use to hack on the
    before/after methods in testing.go. cheers. dorival

    *init_test.go:*
    package mypkg
    import "testing"
    func init() {
    testing.MyBefore = func() {
    /* start here */
    }
    testing.MyAfter = func() {
    /* stop here */
    }
    }

    *testing.go.diff
    *
    118a119,121
    MyBefore = func() {}
    MyAfter = func() {} 427a431
    MyBefore() 456a461
    MyAfter()
    --

    --
  • Joubin Houshyar at Oct 19, 2012 at 4:52 am

    On Thursday, October 18, 2012 11:54:18 PM UTC-4, speter wrote:
    Thanks for sharing this. It is not clear which version the diff is
    applicable to, so it would be nice if you could include the version
    identifier, either using 'hg id' or the VERSION file in the source package.
    (Also, the unified format for diff is preferable as it can be applied even
    if the line numbers have shifted due to unrelated changes.)

    It would also be nice if you could share some more explanation about the
    motivation, why you chose this approach, and what scenarios it is intended
    to be applicable to. It appears to me that this will cause issues when
    testing two or more packages, because they could potentially overwrite each
    others' Before/After functions in initialization,

    It's not a show stopper:

    package <package> // in file <testing.go> analogous to package level doc.go



    func init() { // in <package>_test.go
    testing.Setup["category-name-here"] =
    testing.Setup{
    init: func() {/* .. */},
    fin: func() {/* .. */},
    }
    testing.Setup["another-category-name-here"] =

    testing.Setup{
    init: func() {/* .. */},
    fin: func() {/* .. */},
    }
    }


    A map[string]Setup can go in testing.common<http://golang.org/src/pkg/testing/testing.go#L119>.
    The pain point (from testing package pov) would be a requirement to pattern
    match test func <http://golang.org/src/pkg/testing/testing.go#L357> names
    to the category and call the appropriate Setup before/after funcs.


    func Test<Category><Case>(t *testing.T) { /* ... */ }



    (it's just a sketch ...)


    and the functions set in one package would remain set when testing other
    packages, which I am guessing is not desirable in general. Also, as a
    single package can encompass a wide range of functionality, I'm not sure if
    having common Before and After functions for all tests in a package is good
    practice in general (although it may be suit your specific situation).

    As an alternative approach, I'd suggest you consider using table-driven
    tests: http://code.google.com/p/go-wiki/wiki/TableDrivenTests . With
    table-driven tests, a single function can be used to perform tests for many
    cases in a loop. "Before" and "After" operations that should be executed
    for each test case can simply be written in the loop surrounding the actual
    test case invocation code. And of course it has the big advantage that
    people can compile/test your code with an unmodified Go distribution.
    Peter


    On Fri, Oct 19, 2012 at 7:01 AM, Dorival Pedroso <dorival...@gmail.com<javascript:>
    wrote:
    hi all, i've just thought to share this little patch i use to hack on the
    before/after methods in testing.go. cheers. dorival

    *init_test.go:*
    package mypkg
    import "testing"
    func init() {
    testing.MyBefore = func() {
    /* start here */
    }
    testing.MyAfter = func() {
    /* stop here */
    }
    }

    *testing.go.diff
    *
    118a119,121
    MyBefore = func() {}
    MyAfter = func() {} 427a431
    MyBefore() 456a461
    MyAfter()
    --

    --
  • Dorival Pedroso at Oct 20, 2012 at 12:37 am
    sure:

    diff -r ababb5c0cc6b src/pkg/testing/testing.go
    --- a/src/pkg/testing/testing.go Fri Oct 19 10:12:09 2012 -0700
    +++ b/src/pkg/testing/testing.go Sat Oct 20 10:31:27 2012 +1000
    @@ -116,6 +116,9 @@
    haveExamples bool // are there examples?

    cpuList []int
    +
    + MyBefore = func() {}
    + MyAfter = func() {}
    )

    // common holds the elements common between T and B and
    @@ -425,6 +428,7 @@
    if *blockProfile != "" && *blockProfileRate >= 0 {
    runtime.SetBlockProfileRate(*blockProfileRate)
    }
    + MyBefore()
    }

    // after runs after all testing.
    @@ -454,6 +458,7 @@
    }
    f.Close()
    }
    + MyAfter()
    }

    var timer *time.Timer


    *hg id:*
    ababb5c0cc6b+ tip

    with regards to the motivation, i need to start and stop MPI just once when
    running my tests. for instance, i usually call:
    time mpirun -np 8 go test

    cheers.
    dorival



    On Friday, October 19, 2012 1:54:18 PM UTC+10, speter wrote:

    Thanks for sharing this. It is not clear which version the diff is
    applicable to, so it would be nice if you could include the version
    identifier, either using 'hg id' or the VERSION file in the source package.
    (Also, the unified format for diff is preferable as it can be applied even
    if the line numbers have shifted due to unrelated changes.)

    It would also be nice if you could share some more explanation about the
    motivation, why you chose this approach, and what scenarios it is intended
    to be applicable to. It appears to me that this will cause issues when
    testing two or more packages, because they could potentially overwrite each
    others' Before/After functions in initialization, and the functions set in
    one package would remain set when testing other packages, which I am
    guessing is not desirable in general. Also, as a single package can
    encompass a wide range of functionality, I'm not sure if having common
    Before and After functions for all tests in a package is good practice in
    general (although it may be suit your specific situation).

    As an alternative approach, I'd suggest you consider using table-driven
    tests: http://code.google.com/p/go-wiki/wiki/TableDrivenTests . With
    table-driven tests, a single function can be used to perform tests for many
    cases in a loop. "Before" and "After" operations that should be executed
    for each test case can simply be written in the loop surrounding the actual
    test case invocation code. And of course it has the big advantage that
    people can compile/test your code with an unmodified Go distribution.

    Peter


    On Fri, Oct 19, 2012 at 7:01 AM, Dorival Pedroso <dorival...@gmail.com<javascript:>
    wrote:
    hi all, i've just thought to share this little patch i use to hack on the
    before/after methods in testing.go. cheers. dorival

    *init_test.go:*
    package mypkg
    import "testing"
    func init() {
    testing.MyBefore = func() {
    /* start here */
    }
    testing.MyAfter = func() {
    /* stop here */
    }
    }

    *testing.go.diff
    *
    118a119,121
    MyBefore = func() {}
    MyAfter = func() {} 427a431
    MyBefore() 456a461
    MyAfter()
    --

    --
  • Peter S at Oct 21, 2012 at 9:42 am
    Joubin:
    I agree that your sketch could be the beginning of a more flexible design,
    but it also becomes much more complicated than the original version, and
    I'm not sure whether it is really needed (I have so far found table-driven
    tests with one test function per "category" suitable for my needs) and if
    needed, whether it should be in the standard library. Actually I found
    launchpad.net/gocheck which supports setup/teardown methods for each suite
    and/or all test cases in a suite (project page http://labix.org/gocheck ).

    Dorival:
    Thanks for the details. I'm not well versed in MPI enough to be able to
    tell if the above (arranging cases into table-driven tests and/or using a
    third-party package like gocheck) would be suitable for your needs, but I'd
    probably prefer (and suggest to anyone) to consider those options before
    hacking new features into the Go standard library. I have the impression
    that while using modified versions of the standard packages can be a quick
    solution in the short run, in general it can make code sharing, maintenance
    and troubleshooting more complicated in the long run.

    Peter


    On Sat, Oct 20, 2012 at 9:37 AM, Dorival Pedroso
    wrote:
    sure:

    diff -r ababb5c0cc6b src/pkg/testing/testing.go
    --- a/src/pkg/testing/testing.go Fri Oct 19 10:12:09 2012 -0700
    +++ b/src/pkg/testing/testing.go Sat Oct 20 10:31:27 2012 +1000
    @@ -116,6 +116,9 @@
    haveExamples bool // are there examples?

    cpuList []int
    +
    + MyBefore = func() {}
    + MyAfter = func() {}
    )

    // common holds the elements common between T and B and
    @@ -425,6 +428,7 @@
    if *blockProfile != "" && *blockProfileRate >= 0 {
    runtime.SetBlockProfileRate(*blockProfileRate)
    }
    + MyBefore()
    }

    // after runs after all testing.
    @@ -454,6 +458,7 @@
    }
    f.Close()
    }
    + MyAfter()
    }

    var timer *time.Timer


    *hg id:*
    ababb5c0cc6b+ tip

    with regards to the motivation, i need to start and stop MPI just once
    when running my tests. for instance, i usually call:
    time mpirun -np 8 go test

    cheers.
    dorival



    On Friday, October 19, 2012 1:54:18 PM UTC+10, speter wrote:

    Thanks for sharing this. It is not clear which version the diff is
    applicable to, so it would be nice if you could include the version
    identifier, either using 'hg id' or the VERSION file in the source package.
    (Also, the unified format for diff is preferable as it can be applied even
    if the line numbers have shifted due to unrelated changes.)

    It would also be nice if you could share some more explanation about the
    motivation, why you chose this approach, and what scenarios it is intended
    to be applicable to. It appears to me that this will cause issues when
    testing two or more packages, because they could potentially overwrite each
    others' Before/After functions in initialization, and the functions set in
    one package would remain set when testing other packages, which I am
    guessing is not desirable in general. Also, as a single package can
    encompass a wide range of functionality, I'm not sure if having common
    Before and After functions for all tests in a package is good practice in
    general (although it may be suit your specific situation).

    As an alternative approach, I'd suggest you consider using table-driven
    tests: http://code.google.com/p/go-**wiki/wiki/TableDrivenTests<http://code.google.com/p/go-wiki/wiki/TableDrivenTests>. With table-driven tests, a single function can be used to perform tests
    for many cases in a loop. "Before" and "After" operations that should be
    executed for each test case can simply be written in the loop surrounding
    the actual test case invocation code. And of course it has the big
    advantage that people can compile/test your code with an unmodified Go
    distribution.

    Peter

    On Fri, Oct 19, 2012 at 7:01 AM, Dorival Pedroso wrote:

    hi all, i've just thought to share this little patch i use to hack on
    the before/after methods in testing.go. cheers. dorival

    *init_test.go:*
    package mypkg
    import "testing"
    func init() {
    testing.MyBefore = func() {
    /* start here */
    }
    testing.MyAfter = func() {
    /* stop here */
    }
    }

    *testing.go.diff
    *
    118a119,121
    MyBefore = func() {}
    MyAfter = func() {} 427a431
    MyBefore() 456a461
    MyAfter()
    --

    --
    --
  • Dorival Pedroso at Oct 21, 2012 at 12:26 pm
    sure. I've done this way just because I had already many tests and wanted to try another library that depends on mpi. I couldn't find out another way... cheers. dorival
    On Sunday, October 21, 2012 7:42:52 PM UTC+10, speter wrote:
    Joubin:
    I agree that your sketch could be the beginning of a more flexible design, but it also becomes much more complicated than the original version, and I'm not sure whether it is really needed (I have so far found table-driven tests with one test function per "category" suitable for my needs) and if needed, whether it should be in the standard library. Actually I found launchpad.net/gocheck which supports setup/teardown methods for each suite and/or all test cases in a suite (project page http://labix.org/gocheck ).



    Dorival:
    Thanks for the details. I'm not well versed in MPI enough to be able to tell if the above (arranging cases into table-driven tests and/or using a third-party package like gocheck) would be suitable for your needs, but I'd probably prefer (and suggest to anyone) to consider those options before hacking new features into the Go standard library. I have the impression that while using modified versions of the standard packages can be a quick solution in the short run, in general it can make code sharing, maintenance and troubleshooting more complicated in the long run.


    Peter



    On Sat, Oct 20, 2012 at 9:37 AM, Dorival Pedroso wrote:


    sure:



    diff -r ababb5c0cc6b src/pkg/testing/testing.go


    --- a/src/pkg/testing/testing.go Fri Oct 19 10:12:09 2012 -0700
    +++ b/src/pkg/testing/testing.go Sat Oct 20 10:31:27 2012 +1000


    @@ -116,6 +116,9 @@
    haveExamples bool // are there examples?



    cpuList []int
    +
    +    MyBefore = func() {}


    +    MyAfter  = func() {}
    )

    // common holds the elements common between T and B and


    @@ -425,6 +428,7 @@
    if *blockProfile != "" && *blockProfileRate >= 0 {


    runtime.SetBlockProfileRate(*blockProfileRate)
    }


    +    MyBefore()
    }

    // after runs after all testing.


    @@ -454,6 +458,7 @@
    }
    f.Close()


    }
    +    MyAfter()
    }



    var timer *time.Timer




    hg id:
    ababb5c0cc6b+ tip





    with regards to the motivation, i need to start and stop MPI just once when running my tests. for instance, i usually call:
    time mpirun -np 8 go test



    cheers.
    dorival








    On Friday, October 19, 2012 1:54:18 PM UTC+10, speter wrote:

    Thanks for sharing this. It is not clear which version the diff is applicable to, so it would be nice if you could include the version identifier, either using 'hg id' or the VERSION file in the source package. (Also, the unified format for diff is preferable as it can be applied even if the line numbers have shifted due to unrelated changes.)




    It would also be nice if you could share some more explanation about the motivation, why you chose this approach, and what scenarios it is intended to be applicable to. It appears to me that this will cause issues when testing two or more packages, because they could potentially overwrite each others' Before/After functions in initialization, and the functions set in one package would remain set when testing other packages, which I am guessing is not desirable in general. Also, as a single package can encompass a wide range of functionality, I'm not sure if having common Before and After functions for all tests in a package is good practice in general (although it may be suit your specific situation).




    As an alternative approach, I'd suggest you consider using table-driven tests: http://code.google.com/p/go-wiki/wiki/TableDrivenTests . With table-driven tests, a single function can be used to perform tests for many cases in a loop. "Before" and "After" operations that should be executed for each test case can simply be written in the loop surrounding the actual test case invocation code. And of course it has the big advantage that people can compile/test your code with an unmodified Go distribution.




    Peter




    On Fri, Oct 19, 2012 at 7:01 AM, Dorival Pedroso wrote:

    hi all, i've just thought to share this little patch i use to hack on the before/after methods in testing.go. cheers. dorival





    init_test.go:

    package mypkg
    import "testing"

    func init() {




    testing.MyBefore = func() {
    /* start here */
    }



    testing.MyAfter = func() {
    /* stop here */
    }



    }


    testing.go.diff


    118a119,121

    MyBefore = func() {}
    MyAfter  = func() {}
    427a431


    MyBefore() 456a461
    MyAfter()








    --












    --
    --
  • Joubin Houshyar at Oct 21, 2012 at 1:42 pm

    On Sunday, October 21, 2012 5:42:52 AM UTC-4, speter wrote:
    Joubin:
    I agree that your sketch could be the beginning of a more flexible design,
    but it also becomes much more complicated than the original version, and
    I'm not sure whether it is really needed (I have so far found table-driven
    tests with one test function per "category" suitable for my needs) and if
    needed, whether it should be in the standard library. Actually I found
    launchpad.net/gocheck which supports setup/teardown methods for each
    suite and/or all test cases in a suite (project page
    http://labix.org/gocheck ).
    I merely pointed out that your initial critique can be addressed. gocheck
    is quite good; I have used it before.

    "complicated"

    ymmv, but to date I've found that effective tests of <x> are typically an
    order of magnitude more complex that <x>, but have further noted that the
    complexity is not irreducible. This complexity manifests given the fact
    that specification and verification of construct contracts is typically an
    after thought in most languages. (This is hardly specific to Go and is a
    fairly big topic. I do not claim to have a solution))

    /R

    Dorival:
    Thanks for the details. I'm not well versed in MPI enough to be able to
    tell if the above (arranging cases into table-driven tests and/or using a
    third-party package like gocheck) would be suitable for your needs, but I'd
    probably prefer (and suggest to anyone) to consider those options before
    hacking new features into the Go standard library. I have the impression
    that while using modified versions of the standard packages can be a quick
    solution in the short run, in general it can make code sharing, maintenance
    and troubleshooting more complicated in the long run.

    Peter


    On Sat, Oct 20, 2012 at 9:37 AM, Dorival Pedroso <dorival...@gmail.com<javascript:>
    wrote:
    sure:

    diff -r ababb5c0cc6b src/pkg/testing/testing.go
    --- a/src/pkg/testing/testing.go Fri Oct 19 10:12:09 2012 -0700
    +++ b/src/pkg/testing/testing.go Sat Oct 20 10:31:27 2012 +1000
    @@ -116,6 +116,9 @@
    haveExamples bool // are there examples?

    cpuList []int
    +
    + MyBefore = func() {}
    + MyAfter = func() {}
    )

    // common holds the elements common between T and B and
    @@ -425,6 +428,7 @@
    if *blockProfile != "" && *blockProfileRate >= 0 {
    runtime.SetBlockProfileRate(*blockProfileRate)
    }
    + MyBefore()
    }

    // after runs after all testing.
    @@ -454,6 +458,7 @@
    }
    f.Close()
    }
    + MyAfter()
    }

    var timer *time.Timer


    *hg id:*
    ababb5c0cc6b+ tip

    with regards to the motivation, i need to start and stop MPI just once
    when running my tests. for instance, i usually call:
    time mpirun -np 8 go test

    cheers.
    dorival



    On Friday, October 19, 2012 1:54:18 PM UTC+10, speter wrote:

    Thanks for sharing this. It is not clear which version the diff is
    applicable to, so it would be nice if you could include the version
    identifier, either using 'hg id' or the VERSION file in the source package.
    (Also, the unified format for diff is preferable as it can be applied even
    if the line numbers have shifted due to unrelated changes.)

    It would also be nice if you could share some more explanation about the
    motivation, why you chose this approach, and what scenarios it is intended
    to be applicable to. It appears to me that this will cause issues when
    testing two or more packages, because they could potentially overwrite each
    others' Before/After functions in initialization, and the functions set in
    one package would remain set when testing other packages, which I am
    guessing is not desirable in general. Also, as a single package can
    encompass a wide range of functionality, I'm not sure if having common
    Before and After functions for all tests in a package is good practice in
    general (although it may be suit your specific situation).

    As an alternative approach, I'd suggest you consider using table-driven
    tests: http://code.google.com/p/go-**wiki/wiki/TableDrivenTests<http://code.google.com/p/go-wiki/wiki/TableDrivenTests>. With table-driven tests, a single function can be used to perform tests
    for many cases in a loop. "Before" and "After" operations that should be
    executed for each test case can simply be written in the loop surrounding
    the actual test case invocation code. And of course it has the big
    advantage that people can compile/test your code with an unmodified Go
    distribution.

    Peter

    On Fri, Oct 19, 2012 at 7:01 AM, Dorival Pedroso wrote:

    hi all, i've just thought to share this little patch i use to hack on
    the before/after methods in testing.go. cheers. dorival

    *init_test.go:*
    package mypkg
    import "testing"
    func init() {
    testing.MyBefore = func() {
    /* start here */
    }
    testing.MyAfter = func() {
    /* stop here */
    }
    }

    *testing.go.diff
    *
    118a119,121
    MyBefore = func() {}
    MyAfter = func() {} 427a431
    MyBefore() 456a461
    MyAfter()
    --

    --
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 18, '12 at 10:29p
activeOct 21, '12 at 1:42p
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase