[
https://issues.apache.org/jira/browse/CONTINUUM-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent N Atkinson updated CONTINUUM-2756:
----------------------------------------
Description:
Due to the unfortunate naming convention of the spring and plexus configuration
files, spring-context.xml and components.xml respectively, it is not possible
to load a subset of the configurations on the classpath. This makes is more
difficult to limit the scope of the loaded context, which makes test setup and
teardown much more expensive when not required.
Unfortunately, this convention is common for plexus and not limited to the
Continuum code base. It may not be possible to do this with external
components. In these cases, it may make sense to mock them or at the very least
used cached application contexts to minimize setup/teardown time.
The ultimate issue is the time it takes to verify. It significantly reduces the
productivity of a developer when making changes and the longer feedback loop
has the usual effects (see the reasoning for CI).
The state of the tests in the code base today is that there are very few unit
tests and a limited number of integration tests. The difference in speed with
tests disabled/enabled is 1 minute versus 11+ minutes on a fast system with an
SSD drive. The code would benefit from refocusing on unit testing over
integration tests, but this requires very necessary architectural improvements
to be realistic.
was:
Due to the unfortunate naming convention of the spring and plexus configuration
files, spring-context.xml and components.xml respectively, it is not possible
to load a subset of the configurations on the classpath. This makes is more
difficult to limit the scope of the loaded context, which makes test setup and
teardown much more expensive when not required.
Unfortunately, this convention is common for plexus and not limited to the
Continuum code base. It may not be possible to do this with external
components. In these cases, it may make sense to mock them or at the very least
used cached application contexts to minimize setup/teardown time.
The ultimate issue is the time it takes to verify. It significantly reduces the
productivity of a developer when making changes and the longer feedback loop
has the usual effects (see the reasoning for CI).
The state of the tests in the code base today is that there are very few unit
tests and a limited number of integration tests. The difference in speed with
tests disabled/enabled is 1 minute versus 11+ minutes on a fast system with an
SSD drive. The code would benefit from refocusing on unit testing over
integration tests, but this requires very necessary architectural improvements
be realistic.
> Reduce the time necessary for verification
> ------------------------------------------
>
> Key: CONTINUUM-2756
> URL: https://issues.apache.org/jira/browse/CONTINUUM-2756
> Project: Continuum
> Issue Type: Task
> Reporter: Brent N Atkinson
>
> Due to the unfortunate naming convention of the spring and plexus
> configuration files, spring-context.xml and components.xml respectively, it
> is not possible to load a subset of the configurations on the classpath. This
> makes is more difficult to limit the scope of the loaded context, which makes
> test setup and teardown much more expensive when not required.
> Unfortunately, this convention is common for plexus and not limited to the
> Continuum code base. It may not be possible to do this with external
> components. In these cases, it may make sense to mock them or at the very
> least used cached application contexts to minimize setup/teardown time.
> The ultimate issue is the time it takes to verify. It significantly reduces
> the productivity of a developer when making changes and the longer feedback
> loop has the usual effects (see the reasoning for CI).
> The state of the tests in the code base today is that there are very few unit
> tests and a limited number of integration tests. The difference in speed with
> tests disabled/enabled is 1 minute versus 11+ minutes on a fast system with
> an SSD drive. The code would benefit from refocusing on unit testing over
> integration tests, but this requires very necessary architectural
> improvements to be realistic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
