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
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.