FAQ
https://github.com/coocood/assrt

It embeds a *testing.T, and adds a lot of convenient assertion method.

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

  • Itmitica at Feb 2, 2013 at 8:41 am
    http://play.golang.org/p/fTc76Un55z

    --
    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.
  • Ewan Chou at Feb 2, 2013 at 9:35 am
    I didn't know that interface parameter can not accept integer bigger than
    maxInt

    Is it supposed to be a bug?

    http://play.golang.org/p/-lOffEKvPV
    On Saturday, February 2, 2013 4:41:04 PM UTC+8, itmi...@gmail.com wrote:

    http://play.golang.org/p/fTc76Un55z
    --
    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 Feb 2, 2013 at 9:42 am
    http://play.golang.org/p/hx__98Ngrp

    -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.
  • Ewan Chou at Feb 2, 2013 at 9:46 am
    Thanks, It turns out to be the constants's fault.

    http://play.golang.org/p/QgDglsuU-T
    On Saturday, February 2, 2013 5:42:10 PM UTC+8, Jan Mercl wrote:

    http://play.golang.org/p/hx__98Ngrp

    -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.
  • Dan Kortschak at Feb 2, 2013 at 9:56 am
    Have a look here: http://golang.org/ref/spec#Integer_literals

    The issue (fault is such a harsh word) is that the compiler sees the
    constant as an integer, and the default integer type is int, which is
    currently 32 bits wide. If you specify it as another int type
    explicitly, the compiler can use that.
    On Sat, 2013-02-02 at 01:46 -0800, Ewan Chou wrote:
    Thanks, It turns out to be the constants's fault.


    --
    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.
  • Itmitica at Feb 2, 2013 at 10:48 am

    On Saturday, February 2, 2013 11:46:19 AM UTC+2, Ewan Chou wrote:
    Thanks, It turns out to be the constants's fault.

    No, it's Go's ABC fault: http://play.golang.org/p/lEiTd_3c9P

    http://golang.org/ref/spec#Constants
    Numeric constants represent values of arbitrary precision and do not
    overflow.
    --
    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.
  • Dan Kortschak at Feb 2, 2013 at 9:43 am
    math.MaxInt64 is an ideal constant. If you convert it to int64 that
    example works fine:

    http://play.golang.org/p/T05gnDETaw
    On Sat, 2013-02-02 at 01:35 -0800, Ewan Chou wrote:
    I didn't know that interface parameter can not accept integer bigger
    than maxInt


    Is it supposed to be a bug?

    http://play.golang.org/p/-lOffEKvPV

    On Saturday, February 2, 2013 4:41:04 PM UTC+8, itmi...@gmail.com
    wrote:
    http://play.golang.org/p/fTc76Un55z

    --
    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.
  • Itmitica at Feb 2, 2013 at 10:06 am

    On Saturday, February 2, 2013 11:35:20 AM UTC+2, Ewan Chou wrote:
    I didn't know that interface parameter can not accept integer bigger than
    maxInt

    Is it supposed to be a bug?
    If it's not, it should be.
    The problem doesn't exists for float: http://play.golang.org/p/F7cXTqVJd7

    --
    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.
  • Itmitica at Feb 2, 2013 at 10:08 am
    ... since "erasing" uint and int is out of the question.

    --
    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.
  • Greg Ward at Feb 2, 2013 at 11:08 pm

    On 02 February 2013, Ewan Chou said:
    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.
    Cool. But nobody's going to use it if you don't document it. Life is
    too short to read other people's code to figure out how to use it.

    Greg
    --
    Greg Ward http://www.gerg.ca
    <greg@gerg.ca> @gergdotca

    --
    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.
  • Ewan Chou at Feb 3, 2013 at 2:38 am
    Updated the readme file, thanks for you feedback
    On Sunday, February 3, 2013 7:08:34 AM UTC+8, Greg Ward wrote:

    On 02 February 2013, Ewan Chou said:
    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.
    Cool. But nobody's going to use it if you don't document it. Life is
    too short to read other people's code to figure out how to use it.

    Greg
    --
    Greg Ward http://www.gerg.ca
    <gr...@gerg.ca <javascript:>> @gergdotca
    --
    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.
  • Kyle Lemons at Feb 5, 2013 at 5:58 pm
    There are a number of reasons that assert is not provided in the standard
    library. To name a few:
    - They encourage copy/paste of test cases
    - When an assert fails, you don't get any subsequent errors, which could
    potentially be a better indicator of the problem (usually CHECK is
    purported as an answer to this)
    - Asserts and table driven tests don't mix, because it's difficult to
    explain to the assert library how to only abort a test case and not the
    whole test
    - Assert libraries tend to let programmers be lazy about providing context,
    and helpful messages like "file.go:104: got 33, want 42" are the result.

    On Sat, Feb 2, 2013 at 12:32 AM, Ewan Chou wrote:

    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.

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

    --
    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.
  • Ewan Chou at Feb 6, 2013 at 1:18 am
    But none of your reasons applies to my assert library.
    - less code makes copy/paste less tempting.
    - You can choose "Must" assert to fail now or normal assert to continue to
    test.
    - same as above
    - Assert library always logs expected value, actual value and line number.

    On Wednesday, February 6, 2013 1:58:22 AM UTC+8, Kyle Lemons wrote:

    There are a number of reasons that assert is not provided in the standard
    library. To name a few:
    - They encourage copy/paste of test cases
    - When an assert fails, you don't get any subsequent errors, which could
    potentially be a better indicator of the problem (usually CHECK is
    purported as an answer to this)
    - Asserts and table driven tests don't mix, because it's difficult to
    explain to the assert library how to only abort a test case and not the
    whole test
    - Assert libraries tend to let programmers be lazy about providing
    context, and helpful messages like "file.go:104: got 33, want 42" are the
    result.


    On Sat, Feb 2, 2013 at 12:32 AM, Ewan Chou <coo...@gmail.com <javascript:>
    wrote:
    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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.
  • Ewan Chou at Feb 6, 2013 at 1:22 am
    Wait a minute, how can we abort the whole test suite? test cases are
    independent.
    On Wednesday, February 6, 2013 9:18:13 AM UTC+8, Ewan Chou wrote:

    But none of your reasons applies to my assert library.
    - less code makes copy/paste less tempting.
    - You can choose "Must" assert to fail now or normal assert to continue to
    test.
    - same as above
    - Assert library always logs expected value, actual value and line number.

    On Wednesday, February 6, 2013 1:58:22 AM UTC+8, Kyle Lemons wrote:

    There are a number of reasons that assert is not provided in the standard
    library. To name a few:
    - They encourage copy/paste of test cases
    - When an assert fails, you don't get any subsequent errors, which could
    potentially be a better indicator of the problem (usually CHECK is
    purported as an answer to this)
    - Asserts and table driven tests don't mix, because it's difficult to
    explain to the assert library how to only abort a test case and not the
    whole test
    - Assert libraries tend to let programmers be lazy about providing
    context, and helpful messages like "file.go:104: got 33, want 42" are the
    result.

    On Sat, Feb 2, 2013 at 12:32 AM, Ewan Chou wrote:

    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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.
  • Andrew Gerrand at Feb 6, 2013 at 2:02 am

    On 6 February 2013 12:18, Ewan Chou wrote:

    - Assert library always logs expected value, actual value and line number.

    I think Kyle was being sarcastic. That is not a helpful error message.

    Andrew

    --
    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.
  • Joshua Marsh at Feb 6, 2013 at 12:09 pm

    On Tuesday, February 5, 2013 7:01:58 PM UTC-7, Andrew Gerrand wrote:
    On 6 February 2013 12:18, Ewan Chou <coo...@gmail.com <javascript:>>wrote:
    - Assert library always logs expected value, actual value and line number.

    I think Kyle was being sarcastic. That is not a helpful error message.
    What message would be more helpful? I personally find that information to
    be the most useful, but I'm always open to better and smarter things. When
    a unit test fails, especially one that I didn't write, I want to know where
    it happened, what the expected value was and what actual value was.That is
    often enough information to look at my test cases and see if there is a
    mistake there or if something is wrong with the tested function.

    I can see some value in a library that handles certain common test patterns
    as well. I use one I wrote myself. I've found that 95% of my test cases
    look like this:

    foo, err := doSomeInit()
    if err != nil {
    t.Fatalf("doSomeInit failed: %v", err)
    }

    for i, test := range tests {
    bar := myCoolFunc(foo, test.input)

    if bar.Code != test.Code {
    t.Errorf("(Iteration %d) expected %d from bar.Code but got %d", i,
    bar.Code, test.Code)
    }

    if bar.Body.String() != test.Body {
    t.Errorf("(Iteration %d) expected %s from bar.Body but got %s", i,
    bar.Body, test.Body)
    }
    }

    I'm just simplifying those common cases like:

    foo, err := doSomeInit()
    h.FatalNotNil("doSomeInit", err)

    for i, test := range tests {
    bar := myCoolFunc(foo, test.input)

    h.ErrorNotEqual("bar.Code", bar.Code, test.Code)
    h.ErrorNotEqual("bar.Body", bar.Body.String(), test.Body)
    }

    That looks much more easy to read to me and I get the exact same
    information out of it. If a test fails, both produce something like:

    test.go:85 (Iteration 3) expected "foo" from bar.Body but got "bar"

    The testing.T is still around if I need it to log something more
    substantial, but based on my experience that's a minority of the time.

    --
    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.
  • Kyle Lemons at Feb 6, 2013 at 11:22 pm

    On Wed, Feb 6, 2013 at 4:09 AM, Joshua Marsh wrote:

    On Tuesday, February 5, 2013 7:01:58 PM UTC-7, Andrew Gerrand wrote:

    On 6 February 2013 12:18, Ewan Chou wrote:

    - Assert library always logs expected value, actual value and line
    number.

    I think Kyle was being sarcastic. That is not a helpful error message.
    What message would be more helpful?
    My favorite error messages are generally of the form
    t.Errorf("Function(%v, %v) = %v, want %v", input1, input2, got, want)
    (obviously with %v replaced with more specific or more verbose options as
    necessary)

    So when you see an error like
    strings_test.go:267: Split("", ",") = []string{}, want []string{""}

    You immediately think "D'oh! I forgot that this wasn't supposed to special
    case the handling of the empty string!" and you don't even have to open the
    test file.

    I personally find that information to be the most useful, but I'm always
    open to better and smarter things. When a unit test fails, especially one
    that I didn't write, I want to know where it happened, what the expected
    value was and what actual value was.That is often enough information to
    look at my test cases and see if there is a mistake there or if something
    is wrong with the tested function.

    I can see some value in a library that handles certain common test
    patterns as well. I use one I wrote myself. I've found that 95% of my test
    cases look like this:

    foo, err := doSomeInit()
    if err != nil {
    t.Fatalf("doSomeInit failed: %v", err)
    }

    for i, test := range tests {
    bar := myCoolFunc(foo, test.input)

    if bar.Code != test.Code {
    t.Errorf("(Iteration %d) expected %d from bar.Code but got %d", i,
    bar.Code, test.Code)
    }

    if bar.Body.String() != test.Body {
    t.Errorf("(Iteration %d) expected %s from bar.Body but got %s", i,
    bar.Body, test.Body)
    }
    }

    I'm just simplifying those common cases like:

    foo, err := doSomeInit()
    h.FatalNotNil("doSomeInit", err)

    for i, test := range tests {
    bar := myCoolFunc(foo, test.input)

    h.ErrorNotEqual("bar.Code", bar.Code, test.Code)
    h.ErrorNotEqual("bar.Body", bar.Body.String(), test.Body)
    }

    That looks much more easy to read to me and I get the exact same
    information out of it. If a test fails, both produce something like:

    test.go:85 (Iteration 3) expected "foo" from bar.Body but got "bar"

    The testing.T is still around if I need it to log something more
    substantial, but based on my experience that's a minority of the time.

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

    --
    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.
  • Speter at Feb 6, 2013 at 1:07 pm
    That assert.Nil... I don't think it does what you think it does... For
    example:

    package assrt_test

    import "testing"
    import "github.com/coocood/assrt"

    func TestAssert(t *testing.T) {
    assert := assrt.NewAssert(t)
    var v *int = nil
    assert.Nil(v)
    }

    http://golang.org/doc/faq#nil_error

    On a related note, since you seem to consider testing important (at least
    important enough to write helper methods for it), I'd suggest you also
    consider writing tests for those helper methods.

    Peter



    On Sat, Feb 2, 2013 at 5:32 PM, Ewan Chou wrote:

    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.

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

    --
    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.
  • Ewan Chou at Feb 6, 2013 at 3:10 pm
    I'll fix it.Thank you.

    I didn't write test for assert library because I use it extensively on my
    project, and it works as expected.

    But now I find out that every assert.Nil() is called on error value which
    is not a pointer.
    On Wednesday, February 6, 2013 9:07:02 PM UTC+8, speter wrote:

    That assert.Nil... I don't think it does what you think it does... For
    example:

    package assrt_test

    import "testing"
    import "github.com/coocood/assrt"

    func TestAssert(t *testing.T) {
    assert := assrt.NewAssert(t)
    var v *int = nil
    assert.Nil(v)
    }

    http://golang.org/doc/faq#nil_error

    On a related note, since you seem to consider testing important (at least
    important enough to write helper methods for it), I'd suggest you also
    consider writing tests for those helper methods.

    Peter




    On Sat, Feb 2, 2013 at 5:32 PM, Ewan Chou <coo...@gmail.com <javascript:>>wrote:
    https://github.com/coocood/assrt

    It embeds a *testing.T, and adds a lot of convenient assertion method.

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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
postedFeb 2, '13 at 8:32a
activeFeb 6, '13 at 11:22p
posts20
users9
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase