Unit testing - Autowire and Injecting mock

[abelsky]

Manco,

I'm guessing your com.my.TransactionManager class implements some TransactionManagerInterface somewhere in its hierarchy? I'd try to mock that interface instead of the TransactionManager class itself (use com.my.TransactionManagerInterface as the constructor-arg value of the mockTransactionManager bean)...

A more interesting question is: why do you need to mock the TransactionManager? Is it used directly in the code base?
In my experience, you need the real TransactionManager instance in the Integration tests, but you don't need any TransactionManager in Unit tests...

[Manco]

thanks for the tip, there was an interface. I originally thought it was being used directly.
this is a big body of code that I don't know much about and I am learning both spring and mocks. I am attempting to mock out all parts that I can for my first run. Since, unit testing was not an original priority the layering is not quite as clean as could be.

[Manco]

abelsky,

I have mocked all interfaces, but still there are some instances in the code where
interfaces aren't used and those classes primarily factories extend from a common
base class that implements BeanNameAware, which brings me back to my original
problem. I found the following link http://i-proving.ca/space/Technologi...+Inject-Object Using jMock and Inject-Object, I gave
it a shot but was unsucccessful, an am not sure if it is a valid way to go.

Back to your "the more interesting question is". As I said this is a large body of code that I am unfamiliar with. It has some 650 context xml files. The code that I am working on is a Soap Interface. It connects to the backend via an in-house lib that
connects it to an esb. My code is one of may similar soap clients that use the co.
in-house soap-interface lib. The code was not developed using Unit Testing, which
is why this is not running smoothly, I am not in a position to change the code base.
Essentially the code translates the in-house xml req to the soap req and soap rsp
to in-house rsp. The TransactionManager is used to deal with async rsps. My goal
is to perform a limited integration test, no esb, mock out the txmngr , db access. inject my
code with the xml req, let it run out to a test soap-server/soapUI and compare
actual in-house xml rsp to expected.

Thanks for your help

[abelsky]

Hey Manco,

Here are a couple of thoughts... I don't know the intricate architectural details of your solution, so some of them may not be applicable to your situation.

#1 Since you seem to be set on using mocks in integration tests, I'd recommend giving Mockito a shot (there are some examples in this thread). It's less restrictive, so it will work in your BeanNameAware situation. The setBeanName() calls will be recorded by Mockito-based mocks, but this won't fail the test, and you won't even need to setup any expectations for this to happen).

#2 For integration tests, I always try to instantiate the Spring container without any mocks. It might take some time to instantiate a Spring context with 650 context files, but each subsequent test will inherit it and will run a lot faster. It's usually the easiest solution, and the side benefit is you'll validate the full context with all of its wired dependencies every time it runs.
If I have to provide mocks in integration tests, I try to get away with as few mocks as possible. If I have any JNDI dependencies, I override them by providing these required resources locally (such as data sources, etc). You may, for example, need to mock the ESB proxy if you want to remove the ESB dependency for the integration tests.
Once you're able to instantiate your Spring container in your integration test, you should be able to cover your test scenario - give it an xml request, hit the SoapUI mock service, compare the result, etc. The transaction rollback will roll back database changes (if any) at the end.

#3 Sometimes it makes sense to write a unit test instead, mocking all of its dependencies and verifying the functionality of that class in isolation. In case of a SOAP client, you could still provide a SoapUI mock service for it to hit. Since this is done without any Spring context, this approach should work for you as well.