Category Archives: spring

It’s Been a While

general, spring, work

I just realized it’s been over a year since I last posted. I’ve been thinking I need to get back to posting about technical things I’m working on either on my own or at work.

Some areas I’ve been spending more time in and that I’ll try to post about are Spring 3.1, especially around the new @Configuration options and how they can impact testing, Mongo for fun data management and document storage, and the figuring out the right workflow for our development team in moving towards Git away from Subversion.

On the work front I’ve been to China twice in the last year with most of my time spent in Shanghai.  I was lucky enough to spend a few days each in Beijing, Hangzhou, and Seoul (took a weekend jaunt over to South Korea on the way home).  I’ve also visited a few customers domestically in New Orleans, East Chicago, Northern Indiana, and North Dallas.  It’s pretty amazing to see how our software is being used to help kids learn.

During this last year we’ve also been working furiously towards moving the company’s delivery from on-premise to on-demand and managing to keep a code base that is almost identical in the process.  It’s been interesting to say the least.  We work towards a lot of automated testing wherever possible.  That’s where some of the changes that are coming as part of Spring 3.1 come in handy.

That’s about it for now on the technical update front.

 

Spring Annotations, Spring MVC and an interesting bug in 2.5.1

software, spring, ,

I’ve been doing some work in Spring MVC (Spring v2.5.1) and using annotations to see how simple I can keep my XML configuration (pretty small so far) and while coming across a few interesting gotchas that I’ll be describing in another entry I come across this most maddening problem. If you have a Spring MVC controller defined and it even has an inner class in it, the Spring loader will not find it. It basically ignores it. I had been using inner classes for form beans and validators on some of my controllers and it would just not work. By pulling them out into their own classes, however, everything worked.  That was pretty annoying to say the least.

Here’s the bug: http://jira.springframework.org/browse/SPR-4324

And it is fixed in 2.5.2. So if you’re using annotations in Spring, just go ahead and upgrade. It will save you lots of pain.

The other thing, mind your base packages on annotation scans. I’ll be posting that experience in the next day or so. I’m still slapping my head over that on.

Spring 2.5 Released

software, spring, unit testing, , ,

It looks like Spring 2.5 was released today. I’ve already been using the annotations for both service definition and web controller definition to greatly reduce the size of my configuration files. These are a great addition and I’m sure that I’ll be exploring them a lot in the future.

The other area that grabbed my interest was new integration test classes that support TestNG since previously they didn’t really seem to support TestNG with their test framework.

What Happened to SpringIDE.org?

eclipse, software, spring

When I try going to http://springide.org I get “Hier entsteht eine neue Internetpräsenz” which translates via Google to “Here a new Internet operational readiness level develops”. I’m not 100% what that’s supposed to mean. Any ideas? I think it means the site is under construction. Maybe they’re changing hosting providers. I’m not sure. Anyways, I don’t see anything on the main Spring site, either, so it’s kind of confusing.

Update: Looks like they’ll be back up in a little while. They’re having hardware issues. The update site is still available. Just check out the site and it will direct you.

What a Crappy Blog Entry

eclipse, software, spring

Trying to stay in Tinou’s theme of crappy things I thought I’d talk about his entry, “Spring, what a crappy framework”. The main thing here is that the example points to bad design more than it does why Spring is a crappy framework (it’s not but even if it was). I could easily make that a good design as well and Spring has nothing to do with either approach. I have yet to see how Spring encourages bad design. Rather, it encourages it I believe. Tinou pointed this out as well with respect to encouraging the use of interface driven design. Maybe people are just trying to impose Spring where it’s not supposed to be used within his organization. Pushing a tool where it doesn’t belong is bad no matter how or where it happens. I don’t know, though. Some complain it encourages over complicated configuration. Maybe it’s better to have complicated configurations than it is to have that complication moved into code which tends to be complicated enough as it is.

Now, the configuration. Let’s face it, complex applications are going to have complex configurations. Over time you can simplify them or move towards a configuration through convention approach that Rails has been championed for but it’s always going to start out a little more verbose than it might need to be. In Spring 2.0 it moves forward with the use of XML Schema. Combining that with its support for “components” and you will start to see configurations get less complicated. It will also depend on how you manage your configuration files as well. I know that most people don’t think about this because when I ask people in interviews how they manage complex configurations I get blank stares. Almost every time. I generally tend to break my configurations in to multiple files based on functionality silos. Yes, there are a lot of files but if you know you need to find something about the query factory and/or library then you go to applicationContext.queries.xml and there it is (see, more convention!). Complexity is going to go somewhere and as long as you are consistent and follow your own conventions then its maneagable. I also use Spring BeanDoc to view my Spring configuration and how everything ties together. In addition you can also use the Eclipse Spring IDE (note — the site seems to be down right now) plug-in to help better manage your configuration.

Sometimes you just need to figure out where your problem really lies. It’s not always the tool. Tools can all be misused and most of the time the problem lies between your ears more than in your computer.

Mock Objects – How Useful?

software, spring, unit testing

I have a feeling the title of this post will probably have people thinking I’m going to bash on the concept of them and that’s not really the case but at the same time I think their usefulness tends to be limited to a relatively narrow set of cases.

Where I Have Used Them

Not in as many places as I thought I would. The main area I’m using mock objects (and by the way, I’m using EasyMock 2.0) is in my code that tests some filters that are based on Spring’s OncePerRequestFilter. It makes it easier to test the code when I mock the HttpServletRequest, HttpServletResponse, ServletContext and FilterConfig interfaces. I provide the data that the Spring filter requires and provides during its interaction with these interfaces based on the particular test details. For example, I’ll tell the ServletRequest mock to expect a call to getServletPath and then give it the response as well as setting the run once attribute setting. I’ll also set some items on the FilterConfig that the filter will need. The filter also needs to set an attribute on the request as well.

The reason that mocks come in handy here is that I don’t have to create dummy implementations of these larger interfaces just for testing purposes. Also, the interaction with these interfaces I mock is pretty simple. So basically, they’re great when you have code that interacts with large interfaces but where the interaction is generally limited. More complex interactions would make the mocks, and hence the tests, much more brittle.

Mocks in general work pretty well as long as you’re using interfaces. Easy mock has some features for mocking concrete classes but I haven’t used that feature so I can’t comment on it. They also have some strong limitations, IMHO, that I think should be aware of before going too far with them.

Why Don’t I Use Them More?

There are a number of reasons, but the first that always gets me is I don’t always know how code is going to call the interface if some of my code relies on code I didn’t write or maintain. It means I have a lot of iterations through test cycles before I know how to fully script the mock. Sure I could read through the code but that’s an even bigger pain than the approach I take (at least to me it is). Take my prior example for instance. I had to give the mock to the filter and see where it failed first. If the first call it makes is to the FilterConfig then that will fail. Then it gets past that and I see it fails when it asks for an attribute in the request. And this continues on until I get it right. But that part that gets me is that I’m trying to test my filter, which in this case is a redirect filter, but I’m really doing a lot of work just to get the code I rely to get to the point where I can test my redirect filter’s capabilities. What happens if they make subtle changes in their code but the external functionality no longer changes. My tests break without functionality actually breaking because the use of the interfaces that are mocked no longer respond as they should.

To be fair, if I had created dummy implementations of those interfaces they might not fare a whole lot better since methods I don’t think are going to be called will probably cause the test to fail later on as well. Maybe for common interfaces such as the ones I use above it would be handy to have an implementation that I could easily instantiate that is built for testing interaction with the interface. In general, using code that you didn’t write and then having to test your code on top of that code, will probably be a pain no matter what.

Another reason I don’t use mocks as much as I originally expected to is because in general most of my services are built with testability in mind so I don’t need to mock up a lot of interfaces to test them. I can feed them data and they just work with the test data. Mocks tend to work best in cases where I have to deal with external systems more than anything and there aren’t suitable classes available that take the necessary test data for the code to function the way I need it to for my tests. Overall, I’d really rather have my unit tests run through real code where possible vs. mocks because then I know the interaction works where as a mock could provide a disconnect with the real system in some cases.

I suppose I’m lucky that with my personal projects I have the luxury of building code for testability in the first place so I don’t have cases where I have no choice but to mock up a more complicated interface. In my work projects most of my code deals with code generation and persistence so mocks really aren’t all that necessary for my work. How are you using mocks? Are there scenarios I don’t have to deal with that you’ve come across and where they’ve really simplified your testing life?