[all] Always assert NotNil for values that, eh, shouldn't be nil ;)

[zeroXten]

Most returns are either "nil, error" or "something, nil". Need to catch accidental "nil, nil"

[jonbonazza]

I noticed also in many of the unit tests you are doing things like asserting NotNil for errors and NotEquals for slice lengths.

The assert package has some more sophisticated functions like NoError (), Error(), Len(), etc... We should take advantage of these where possible.

[zeroXten]

Next you'll be suggesting that I read the documentation ;)
On 29 Jan 2015 19:52, "Jon Bonazza" [email protected] wrote:

I noticed also in many of the unit tests you are doing things like
asserting NotNil for errors and NotEquals for slice lengths.

The assert package has some more sophisticated functions like NoError (),
Error(), Len(), etc... We should take advantage of these where possible.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[jonbonazza]

Lol Did I miss something in the docs? :x

On Thu Jan 29 2015 at 11:56:45 AM Fraser Scott [email protected]
wrote:

Next you'll be suggesting that I read the documentation ;)
On 29 Jan 2015 19:52, "Jon Bonazza" [email protected] wrote:

I noticed also in many of the unit tests you are doing things like
asserting NotNil for errors and NotEquals for slice lengths.

The assert package has some more sophisticated functions like NoError
(),
Error(), Len(), etc... We should take advantage of these where possible.

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

[zeroXten]

No no. I think I saw an example that include NotNil and Equal and just ran with those, rather than reading the other possibilities.

[jonbonazza]

Ah gotcha. haha Yea, there are a load of options. I am only familiar myself
with a handful of them, so don't feel bad. haha

On Thu Jan 29 2015 at 1:47:52 PM Fraser Scott [email protected]
wrote:

No no. I think I saw an example that include NotNil and Equal and just ran
with those, rather than reading the other possibilities.

—
Reply to this email directly or view it on GitHub
#8 (comment).