catergorize methods in class
there are two kinds of methods in one class, no matter what kinds of languages you use or applications you build: element methods (this is an ambiguous name, I know) and composed methods.
stick to this principle no matter what class we design (repository, or model, or presenter in mvp), the class will be more maintainable.
sometimes, it is tricky to work out all these steps that would involved in the composed methods, that doesn't matter! :) in some extent, the implementation and the test just drive each other!
and sometimes, it would seem that the state-based testing for the composed method is a kind of wast, after all, you just repeat the logic in the implementation (if you do test-driven development) or in the test (if you don't do tdd), some guys in our project even call it "faked confidence". I don't agree with that, cause it happens many times in our project that the (state-based) unit tests help us drive the design and catch the bug. but I would admit that modifying the state-based testing after the requirement alteration is annoying.
1. element methods
the responsibilities of element methods are realizing part of an algorithm, like doing a searching or sorting or setting up a component. they are implementation-oriented. so they are named from the technical point of view. and generally, the access control level for them should be private or protected.testing element methods
the unit testing strategy for element methods generally would be result-based testing, that is, after carrying out a series of invocations and calculating, you assert the result as expected.2. composed methods
these methods are responsible for realizing the whole algorithm by composing these element methods, there's no concrete calculating or lib invocations, just calling to element methods. composed methods are business-oriented, and they are public.stick to this principle no matter what class we design (repository, or model, or presenter in mvp), the class will be more maintainable.
testing composed methods
the unit testing strategy usually used for composed methods is state-based testing, that is, before implementing composed method, it would be helpful to come up with the steps you gonna use to implement the business logic, and use the expectation to drive your implementation. (ref http://martinfowler.com/articles/mocksArentStubs.html)sometimes, it is tricky to work out all these steps that would involved in the composed methods, that doesn't matter! :) in some extent, the implementation and the test just drive each other!
and sometimes, it would seem that the state-based testing for the composed method is a kind of wast, after all, you just repeat the logic in the implementation (if you do test-driven development) or in the test (if you don't do tdd), some guys in our project even call it "faked confidence". I don't agree with that, cause it happens many times in our project that the (state-based) unit tests help us drive the design and catch the bug. but I would admit that modifying the state-based testing after the requirement alteration is annoying.