Retrofitting Unit Testing into existing J2EE project
Hello
I think this is the right place for this...
anyway, so being a new hire I'm trying to get the new operation onto the unit testing bandwagon. I've met with success from management, which is good, but the project is built in such a way that makes unit testing extremely difficult.
There are 2 things that contribute to the mess.
1. Sping/Struts integration means all the config files are specified in web.xml independently, even though their beans rely on each other across files. End result is in a unit, I cannot try to load a bean because some of its dependencies are missing (ie. they are in a config file that the first file does not include).
2. Datasource beans are loaded in the app container using jndi. So when I try to instantiate a DAO in a test, it cant find its datasource because its not being instantiated in a container...
Is there any way to get around these hiccups programmatically in unit tests?
One solution I can see is to maintain seperate configuration for unit testing project. Naturally I dont want to do this--the configurations are massive and its probably sloppy practice-wise.
thanx...
# 1
> Hello
>
> I think this is the right place for this...
>
> anyway, so being a new hire I'm trying to get the new
> operation onto the unit testing bandwagon. I've met
> with success from management, which is good, but the
> project is built in such a way that makes unit
> testing extremely difficult.
>
> There are 2 things that contribute to the mess.
>
> 1. Sping/Struts integration means all the config
> files are specified in web.xml independently, even
> though their beans rely on each other across files.
Spring should be making your testing life easier. What's Struts got to do with it?
If you're saying that all the logic is stuffed into the Struts Action class, and that's making it harder for you to test, I think the answer is to move that code out of the Action class and into a service with an interface. Then you can test it without the web tier.
If you're talking about system integration tests with the UI, see if Selenium can help you automate those tests. You can use it to capture those as JUnit classes.
> End result is in a unit, I cannot try to load a bean
> because some of its dependencies are missing (ie.
> they are in a config file that the first file does
> not include).
Maybe you need to refactor your configuration.
> 2. Datasource beans are loaded in the app container
> using jndi. So when I try to instantiate a DAO in a
> test, it cant find its datasource because its not
> being instantiated in a container...
It's common for Spring to have a separate app context just for testing that uses the DriverManager connection instead of JNDI. I do it that way. Since you're doing database testing, I'll assume your DAO JUnit tests extend the AbstractTransactionalDataSourceSpringContextTests, which allows you to specify where all the config files are in the CLASSPATH. It also makes all your tests transactional without any effort on your part. Run your tests, trash the data, and it's all magically rolled back when you're done. It's as if you were never there.
> Is there any way to get around these hiccups
> programmatically in unit tests?
>
> One solution I can see is to maintain seperate
> configuration for unit testing project. Naturally I
> dont want to do this--the configurations are massive
> and its probably sloppy practice-wise.
Not sloppy, necessary. If your configurations are that massive, it's time to refactor them, anyway. I tend to partition mine along package lines.
%
# 3
> One solution I can see is to maintain seperate
> configuration for unit testing project. Naturally I
> dont want to do this--the configurations are massive
> and its probably sloppy practice-wise.
Development environment, production environment, testing environment, and quality assurance environment should be in their own enviroments with no dependencies on other environments.
Each configuration for each environment should be suited for achieving the goals of that particualr software area. Having a separate environment for each area may be costly for some applications/organizations. However, if you are dealing with an application that makes money, then separate enviroments is necessary and good practice.
