Just one piece was missing for me – how to retrieve the mocks from the Spring application context to setup my test case.

Here’s what I did (using mockito):

- in testApplicationContext.xml:

<bean id="myService" class="org.mockito.Mockito" factory-method="mock">
<constructor-arg value="com.myproject.MyService" />
</bean>


- in the test class:

XmlWebApplicationContext applicationContext = (XmlWebApplicationContext) sandbox.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
MyService myService = (MyService) applicationContext.getBean("myService");
when(myService.doSomething()).thenReturn(something);


Just wondering if this is the right way to do?

As usual, very insightful comments!

With respect to the static analysis tools, my example was a bit of a throw-away: years ago when I had the problem, the IDE in question (eclipse in fact) didn’t have that sophisticated a set of static analysis tools, so it didn’t highlight my error, but that’s not really the point. As you allude to, my point was sometimes simple things add value, and so the advice to “test what’s likely to break” is somewhat difficult to follow. It’s also difficult for a static analysis tool to say “that’s wrong” usually they’re limited to saying “that’s suspicious.” People have to do the thinking, and that’s where we have to use unit tests to capture the intention of the code. Static analysis will, I think, always be limited to flagging things for further review, until computers become sentient (I for one welcome our new computer overlords).

I’m also conflicted about your last point: advocating for a unit test for just a setter and getter. In fact I think I am in fact advocating for that. I could deduce the function of the test from other, higher level functions that use the property in question, but when they failed, it might take me quite a while to figure out why (and in fact, it did take me quite a while). If the “unit” that I’m testing is an entity, then I think I come down on the side of writing a test for the getter/setter pair, even if it’s tested elsewhere.

- Keith

I won’t argue with the validity of your post. As usual, you are talking about good stuff, and right on. I will say, however, that I feel not enough people rely on the compiler and static analysis tools to assist. The goal of your unit tests is to insure your production software is doing the right thing. In my mind, that is also the goal of the compiler and static analysis tools. Both of which people seem to discount. In fact, I’ve seen that very issue you identify highlighted in Eclipse when configured correctly so you’d have a much harder time missing it. In this particular case I believe the tool that would identify the condition was CheckStyle. We’ve had a zero warnings policy and the first time you do something like this it will stick out on the warnings tab like a sore thumb. It can catch tons of simple things like single equals instead of double, poor null handling, etc.

If you are using a dynamic language, you have a lot more of this burden placed on your unit tests. That fact makes me conflicted as to whether I’m a fan of them or not.

Again, I am strongly in agreement that unit tests (and TDD) are invaluable to a development project. I’m just out to promote other tools that can assist as well.

One other thing I will say is that I expect you are not advocating a simple test specifically for the getter and setter in this case. In my opinion, unit tests are great, but if something like that isn’t exercised by a unit test that provides value in some other way, it is likely dead code (although it wouldn’t have required you to look at it for a day if it were dead code, obviously). TDD helps to keep code clean in that respect, in a way 100% unit test coverage metrics doesn’t.

Jason

I appreciate your points. I think your definition of “signed off” corresponds nicely with “reviewed by stakeholders” in the continuum above. I think that it’s a good place to aim for in terms of done-ness.

In some projects, for better or worse (mostly worse), the product owner isn’t available during the sprint to review, and only shows up at the end of the sprint (and sometimes not even then) so it’s sometimes a challenge to get something signed off and still get the kind of regular feedback we need in order to measure progress.

I always like to have at least two stories per iteration, even if that means making them small, so at least the team gets something done, and we don’t have an all-or-nothing velocity computation as a result.

In the end, it’s up to the team to decide on the most “advanced” definition of done they can accomplish, based on the constraints of the individual project. It’s in everyone’s best interest they balance the remaining uncertainty against the need for feedback in a timely fashion.

A term that I’ve used and seen used is “signed-off”. From the development team’s perspective, I think the “gate” that is most important, or at least hits the sweet spot, is this one. My definition of signed-off is when someone responsible for delivery of the functionality can confirm they have been given what they requested and/or need. On some projects I’ve seen the project owner give developers sign-off after quickly checking out a change on the development server where it was freshly deployed (a high level of trust between project owner and development team existed in that case). On other projects I’ve seen sign-off only occur when a QA team resource has written passing automated unit tests AND a business team has confirmed that the functionality does what is needed.

It seems pretty common in my experience for teams to stack up a pile of “dev-complete” stories that haven’t been seen by anyone until the big-bang testing cycle before production release. That is a big red flag that the release is at risk, and a fire-drill is looming.

One of my favorite agile projects I’ve been involved with required the developers to “demo” the story to the “customer” (XP project) in order to get sign-off. No story points counted against the iteration without that sign-off. It prevented too many stories from building up. (On a side note, I distinctly recall part of the demonstration for one story actually required me to crawl under my desk and pull the network cord out of the wall, demonstrate a failure, plug it back in before showing the subsequent success — at the request of our customer who was watching.)

So from my perspective, the spot on the done continuum I believe is most worthy of focus would be getting stories signed off. If the development team indeed delivered the functionality that meets the stakeholders’ needs, and those stakeholders have demonstrated that to themselves somehow, then getting that code deployed to the production environment is an orthogonal problem (albeit, a critical one).

Now, the other related question I’ve also seen along the lines of this topic are — how many stories makes a release done? That’s a whole different discussion.

Sorry for the ramblings. I hope you feel this is all on-topic with your ideas of what done means.

Jason

The problem is that most people don’t understand what you do, namely the spirit of agile and not its implementation.

You may like this, which also has some comments on the matter.

http://www.financialagile.com/reflections/9-general/104-followers

J