Invariant support [#289, #81557010]

[xtreme-james-cooper]

Changes to allow the automated testing of class invariants, as explained in issue #289

[xtreme-james-cooper]

This implements the semantics in the issue pretty closely, but there are still some open questions, which I've listed back on the issue.

[tooluser]

On Oct 30, 2014, at 9:39 AM, xtreme-james-cooper [email protected] wrote:

This implements the semantics in the issue pretty closely, but there are still some open questions:

Pending tests. After consultation with @pivotal-brian-croom https://github.com/pivotal-brian-croom , we decided to make it so that invariants are not run in pending test blocks. This seems reasonable on the one hand since the point of pending tests is to remind you to write them, but on the other hand I can see a use case where we stub out a whole pile of flow and just let the invariant roam automatically over it. it(@"force invariant", ^{true should be_truthy}); at the leaves would work, but obviously that's inelegant.
This seems good - it goes with a discouragement of ‘pending’ specs and keeps their handling uniform.
Scoping. Invariants seem, to me, to be the kind of thing that you should put at the top of a file en masse and then have true everywhere. However, since they're just created by a method like everything else, you can put them wherever and create context-local invariants. I am not yet sure if this is a feature or a bug.
This to me seems like a huge feature & significant use case.
“Once the user has hit this button, the following invariant(s) should hold.”

=

[idoru]

Please follow this thread on the rebased pull request, #388