add IsTrue / IsFalse checker + ran gofmt

[pattyshack]

our tests at dropbox has a lot of

c.Assert(value, Equals, true)
c.Assert(value, Equals, false)

using IsTrue / IsFalse seems simpler.

[niemeyer]

Hey Patrick,

I'm slightly on the fence about this one, mainly due to it being just an alias to something very close to it, (Equals, true) which matches exactly the usual Go operation (== true). The original reason we have IsNil was because it is not quite equality that we're verifying there. It was cumbersome to test the "interface has a type but is nil" case.

Is it so much better to have IsTrue than Equals, true?

[pattyshack]

I wouldn't necessarily say better; it's just shorter (It's down to personal perference).

I understand the technical reason behind IsNil. To me, IsTrue / IsFalse is more akin to NotNil than IsNil, since NotNil is just a short hand for Not(IsNil).

[niemeyer]

NotNil is a dubious choice indeed, which got added on the back of IsNil's distinctive demand.

If you don't mind, I'd prefer to keep the line more clear for adding those helpers, to prevent us from adding too many little helpers which offer little in comparison to straight checks, in the name of saving a few characters.

We do need some additional standard checkers, and these are the ones that make a boring case trivial, or that improve the debugging information provided to the developer when the test fails. I can think of "Contains", and the counterpart "In", for example. I'd also like to have a checker to test that a value falls within a range, but I couldn't come up with a word that is not ambiguous or extreme long for those ("Between" doesn't make clear if the interval is closed or not).

[pattyshack]

ok, I push this into https://github.com/dropbox/godropbox instead.

[niemeyer]

That works, and it was a specific design goal to have custom checkers well supported, even one that is specific to the context of a single test if necessary, so you can rest assured it'll remain working.