Unit tests should properly close or destroy any Spring ApplicationContexts which they create
Basics
Logistics
Basics
Logistics
Description
If the context isn't closed properly, it doesn't invoke the destroy() lifecycle on its beans, which can lead to cruft lying around.
Noticed initially on metadata provider parser tests in idp-profile-spring net.shibboleth.idp.profile.spring.relyingparty.metadata. File caching HttpClients are leaving their cache data accumulating in the configured cache dir.
I'd wager there are lots of other examples.
Some could be easy to fix with try-with-resources (contexts are Closeable), depending on the test structure. Others might require creative use of TestNG @AfterMethod/-Class/-Suite, etc.
Environment
None
Activity
Rod Widdowson
August 17, 2015 at 1:34 PM
R7685 (idp) R814 (spring extensions)
Rod Widdowson
August 16, 2015 at 3:44 PM
Checkins 7681, 7682, 7683, 7684 do attribute filter, attribute resolver, and an odd spring test in profile-api.
Still to do irp-profile-spring, idp-saml-imp and possible SpringSupport (the project)
If the context isn't closed properly, it doesn't invoke the destroy() lifecycle on its beans, which can lead to cruft lying around.
Noticed initially on metadata provider parser tests in idp-profile-spring net.shibboleth.idp.profile.spring.relyingparty.metadata. File caching HttpClients are leaving their cache data accumulating in the configured cache dir.
I'd wager there are lots of other examples.
Some could be easy to fix with try-with-resources (contexts are Closeable), depending on the test structure. Others might require creative use of TestNG @AfterMethod/-Class/-Suite, etc.