- investigate where/why check for existence of stubbed method has gone.
- provide test::unit agnostic api - mockery/context type objects on which the user must call setup/teardown?
- increment actual count for ANY expectation that matches - see email from Bryan Helmkamp
- add multiyield - see email from Jay Fields
- think about allowing a stubbing expectation to be converted to an asserting expectation and vice versa
- fail fast if expectation count exceeded during test...? c.f. JMock?
- object methods needed for mocha itself should be aliased to __xx__ versions
- maybe introduce blank_mock() and blank_stub() methods or make Stub include Object methods and Mock not...?
- tags for repos
- read and improve tutorial emailed by user
- reduce number of methods added to Object, Class etc to bare minimum
- reduce number of methods excluded from undef in mock_methods (maybe use blank_slate as mocha parent class to allow mocking of standard object methods?)
- should we get two errors when unexpected method is called and similar expectation is not fulfilled? i.e. should we raise error in teardown if one has already been raised in test?
- default mock names to mock1, mock2, etc or something similar
- stubba mocks should named according to parent stubbee
- allow specification of class to be mocked so we can check for existence of methods
- oomatron type ideas
- allow stubbing of private/protected methods? - force_stub?
- allow hash parameter for stubs and expects methods particularly for stubba
- use real activerecord as svn external to for testing instead of active_record_test_case
- provide some means to un-stubba an object - ideally should restore any methods with same names as stubba methods c.f. dealing with expectations for methods called :expects, :stubs, etc.
- automate releases cf rspec
- think about behaviour when more than one expectation/stubbed method match c.f. JMock?
- make verify method private (makes this unnecessary - fail if attempt to verify stub)
- test for setting expectations on class methods (and instance methods?) from within TestCase#setup
- use Object#inspect(:mocha) or Object#__inspect__ instead of Object#mocha_inspect?
- should all instances share expectations for any_instance or should each instance have their own - in which case how do we provide access to the instances
- detect existing or added definition of mocha methods e.g. expects and alias to __expects?
- more jmock style stuff - e.g. labels/required order, more sophisticated param matching?
- stubs should only return a fixed value - no blocks allowed for return values and no parameter expectations allowed?
- maybe allow unstubbing of a specific method from within a test...?