There are two ways I usually solve this problem. The choice between
the two (for me) is usually a matter of how deep I want the testing to
go.
In many cases, I use spring injection from my unit tests by combining
JUnit's @RunWith annotation and some Spring Annotations. Here is an
example -
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations =
{"classpath*:applicationContext-test.xml"})
public class StockInfoManagerTest {
@Autowired
@Qualifier("stockInfoDao")
private GenericDao<CDOV_StockInfo,String> stockInfoDao;
This is mostly self-explanatory... However, I will mention that I
usually don't point to the same applicationContext.xml file that I
would use for production. In this case, I configure spring to
instantiate and talk to an hsqldb database. Then I can push stuff in
and then pull it back out to ensure that database operations complete
successfully.
In many other cases, I prefer a "mocking" approach. Here is an example -
�...@test
public void executeTest() throws Exception {
// setup the mock object
final StockInfoManager stockInfoManager =
context.mock(StockInfoManager.class);
// create expectations for mock object's execution
context.checking(new Expectations() {{
oneOf(stockInfoManager).getAll(); will(returnValue(new
ArrayList<CDOV_StockInfo>()));
}});
What mocking does is create a proxy that records requested operations
and behaves the way you describe it. The advantage of mocking is that
you don't have to worry about fully populating dependencies, etc. If I
feel like the implementations that get wired in at production have
already been properly tested, then I will use mocking to test.
In my case, typically, I will fully test services by wiring them with
Spring and having them hit a test database (usually embedded like
hsqldb or derby). Then, once I am confident that the services do what
they advertise, I will unit test the user interface actions (Struts 2
actions, in my case), but injecting mocked services and work on making
sure that the actions operate the way I intend (by setting the mock's
expectations then interacting with the action the way I expect the
framework to call them).
Of course, this is really somewhat outside of the scope of a
maven-users list... If you want to get into the theory of good unit
testing, I think there are a few good books out there. Otherwise, just
get familiar with at least these two techniques and try to
consistently apply a set of practices that best tests your code (as
opposed to attempting to test each and every element of your
application's setup).
-Wes
On Mon, May 3, 2010 at 9:15 AM, Dan King <dan.king...@yahoo.com> wrote:
> Hi all,
>
> I have a webapp (sub)module that uses Spring's dependency injection; how
> can/should I load the application context so I may run the unit tests for
> this module?
>
> Once all the modules are complete, I will add them to the webapp as
> "dependencies" and load the application context via the web container and
> Spring's "ContextLoaderListener."
>
> -Dan
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
