Aspect for Autopopulating Entities While Testing
Was watching one of the guys on our team the other day testing a wizard. In order to see what was going on on the third page, each time he ran the app, he had to fill out the first two pages, and then use the upload component to upload a bunch of files, each time.
I have thought about this problem before. Of course, one would think that the easiest way to solve it would be in Spring itself, but alas, it isn't. Ideally what we would want is for some of the entity's properties to be prepopulated so we can just click through to the page in question.
Spring should be great at this, after all, wiring properties is one of its strengths. But to do it, you would have to go in and change the definition, then remember to put it back, etc. Bad idea.
So this time I got to thinking first about doing a bean post processor that would go look for a mock version of the bean. While discussing it, we decided instead to do an aspect. The code ends up being super simple:
The aspect is declared in the Spring file. This is done so that we can have a separate bean file for the dev profile that is not included in the production build, so no matter what is left lying about in there, we don't have to worry about waking up to find out that some obscene name was autoappearing in various runtime forms.
The idea is simple: let's say you have a bean called Story which has headline, contents, etc. You make another bean called storyMock. Then you wire this bean into the interceptor. There, it is put into a map with the class as the key. The pointcut is on all get methods. When the interceptor is called, it checks to see if it has a bean of that type. If it does, it invokes the get method on the mock bean instead then returns the result (advice is around). So you can see, the properties we have wired into the mock will magically appear in the regular bean.
While I was rooting around for some answers on various aspects of doing this, I saw Cedric bagging on an aspect-based solution for injecting values into unit tests for being 'too much magic' (I agreed); this one I think is just the right amount of magic. Of course, this fits well into the *Lean* jag I have been on for a while: mind the VSM. The other big advantage I think is that as you harden parts of the interface you can just completely ignore them, which will lead to more/better attention to usability (less cumulative drag as it were). I also think this is a great example of the usefulness of aspects because it is kind of an environmental thing, but it's also very simple to use for the guy who didn't make the aspect. Note that the actual chaining code is like 2 lines. (Not as impressive as all those one line solutions to Cedric's recent challenge, but then, this code does something. ;) )