Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Modularity in Spring Configuration

DZone's Guide to

Modularity in Spring Configuration

· Integration Zone
Free Resource

Are your API program basics covered? Read the 5 Pillars of Full Lifecycle API Management eBook

The following goes into more detail what I already ranted about in one of my previous post.

In legacy Spring applications I have to develop new features in, I regularly stumble upon a big hindrance that slows down my integration-testing effort. This hindrance, and I’ll go as far as naming it an anti-pattern, is to put every bean in the same configuration file (either in XML or in Java).

The right approach is to define at least the following beans in a dedicated configuration component:

  • Datasource(s)
  • Mail server
  • External web services
  • Every application dependency that doesn’t fall into one of the previous category

Depending on the particular context, we should provide alternate beans in test configuration fragments. Those alternatives can either be mocked beans or test doubles. In the first case, I would suggest using the Springockito framework, based upon Mockito; in the second case, tools depend on the specific resource: in-memory database (such as HSQLDB, Derby or H2*) for datasource and GreenMail for mail server.

It is up to the application and each test’s responsibility to assemble the different required configuration fragments to initialize the full-fledged Spring application context. Note that coupling fragments together is also not a good idea.

* My personal preference goes to H2 these days

Establish API creation, publishing and discovery as a master practice with the API Management Playbook.

Topics:

Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}