Mocking private methods while testing

Having been working with mocking frameworks for quite sometime, mostly easymock, I always wondered some way of mocking the private methods and then testing them in isolation as I would do for any non-private methods. There has been no direct support for doing this in any of the popular mocking frameworks till now. So I was left with very few options

• Make them protected ( a hack as this is going to break my design and encapsulation), thus making it available to test in isolation. Also now I can override that method with an empty implementation while testing other public/protected methods which makes a call to this method, thus in a way trying to stub it.

• Leave them as private and have them tested as part of another method test so that it is covered as part of code coverage tool, but still has no way of testing it in isolation and also at the same time it might get executed multiple times if it is invoked from multiple methods

But recently I came across another mocking framework powermock which is sort of extension on top of easymock to allow mocking of not all private methods but also of static methods, constructors, final methods etc. It uses bytecode instrumentation and a custom classloader to do this which is OK but a little more intrusive then what I would have liked.

There is good enough documentation to depict how to mock private methods here . Also it provides some useful reflection utilities which can be used in unit testing private methods, some examples of which can be found here

Waste Elimination

Waste by definition, is garbage or rubbish and elimination of it quite literally means removing the bad, rotten, stinking practices from our software development process and code smells (a side effect of not eliminating the rubbish) from our implementation.

When we talk about lean manufacturing or more precisely eliminating the waste, then essentially what we are talking about is

• Delivering what makes sense to the customer and nothing more, as anything more is a waste. Try and help the customer distinguish between what he really needs against what he might need.

• Keep paying off the technical debt as soon and as much as possible. I consider paying off technical debts as synonymous to eliminating waste.

• Keeping a constant flow of work and working at a sustainable pace, eliminating the chance of dip in productivity, quality and motivation.

• More lines of code when less can do, is a waste. How often we have looked at a big massive codebase and thought to ourselves. What a waste? Get rid of it and every time I have a done it I have felt very good about it. Just think of it as if removing even few grams of weight from your backpack while travelling on an adventurous trip. Code light and it will definitely pay off

• Eliminate the artifacts which states what we are going to do, by really doing it. Non working, out dated artifacts is something we should always avoid

• Eliminate specialist roles as that would promote collective ownership and passion to collectively work for the success of the project.

A big part of being agile is doing ‘Just Enough’

Just Enough Requirements: The idea is not to get down to the finest details up front, capture just enough information which will enable team to estimate the development time for the requirement (in a form of user story) with a window to have a discussion with customer at a later time for the needed functionality. By going lazy with the requirement gathering, we are sure what is being developed is really what the customer want. Guy Beaver supports this in his article on The Challenge of Enterprise Requirements Management

The suggested solution is to replace early detailed specification with solution road maps that can be detailed by collaborative teams at just the right time. Agile methods provide the structure and mechanics to allow business vision to lead product development with cross-functional teams that unfold detailed requirements when needed

My Article on AgileAlliance

Please visit the link below to read about my article on how agile practices makes a distributed team get closer to the onsite team and how it encourages one team feeling

http://www.agilealliance.org/show/1924

User has so many Stories to tell

When introduced into agile way of working I have always considered user stories as use cases and as I went about estimating and implementing these user stories, I found it out they vary a lot in nature

Easy to plan

User Stories are much easier to plan and estimate and thus forms the basis of iteration planning and is meant to implemented in a single sprint and ideally should not be carried over to the next sprint. This leads to a big advantage that can be prioritized. So a user story is much smaller in scope and lasts much shorter then a use case.

Leave the details for later

It is never meant to be always complete and more often then not are replaced by storied with greater detail when required. This enable an agile team to start with a set of broadly specified user stories to give a good idea about the application. Further the way they are made it always promote verbal communication. So a clear distinction is in the amount of completeness.

Let you be up and running very quickly

I do not have to have every single detail flushed out for a use case to start to work on it. Team can always start on one user story which make up that use case.

Agile ways

Agile methodology is like running marathon in 100m chunks