[
http://jira.amdatu.org/jira/browse/AMDATU-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11490#comment-11490
]
Bram de Kruijff commented on AMDATU-418:
----------------------------------------
I'm unsure how to deal with this. A few notes:
Issues:
1) The implementation is implicitly/tightly coupled to artifact final names and
configurations of final zip distributions. It currently breaks on changed zip
filenames and expected auth services
2) It is not integrated (and it is not so easy to integrate) it into build
and/or automated testing frameworks as it is developed as a standalone tool.
3) Bridge services to test specific functionality over rest without an existing
interface require additional artifacts to be build and deployed into the test
container.
4) No remote test execution (jmeter en amdatu on same machine)
One option is to move the test execution to the itest framework. This offers
amdatu launching with customizable pax provisioning (including test code such
as bridges) and dependency management to address service availibility etc.. In
pseudo code:
@Test
public void testPerf(BundleContext bundleContext) throws Exception {
TestContext testContext = testContextSetUp(bundleContext);
Dictionary<String, String> props = new Hashtable<String, String>();
props.put("alias", "/hello");
Component component = testContext.getDependencyManager()
.createComponent();
component.setInterface(Servlet.class.getName(), props);
component.setImplementation(TestServlet.class);
testContext.addComponent(component);
runJmeter("amdatu_testhello.jmx");
testContext.tearDown();
}
This test could be configured to be run multiple times against different
versions (eg. local snapshot versus last stable release) or even osgi
frameworks (felix / equinox) through simple maven configuration without
affection the code. However...
1) This requires we decouple the analysis stuff from the test stuff and move it
to the maven reporting phase. With an upsite that is can be uploaded with site
just like other reporting data. This could allow us to publish performance test
results with every release instead of managing and emailing eachother random
xml files.
2) Although now it is in one software module, maintenance still requires
keeping java code and jmx script in sync.
3) This still does not support remote testing.
So... if we want to keep perf testing I think we should integrate it with
itest. But, if we feel we should be able to do serious remote distributed
benchmarking above the level of itesting it is probably better to manage perf
tests and testserver seperately. The latter first by hand an hooking them up to
provisioning once that is avalable.
> Restore performance test framework and implement platform tests
> ---------------------------------------------------------------
>
> Key: AMDATU-418
> URL: http://jira.amdatu.org/jira/browse/AMDATU-418
> Project: Amdatu
> Issue Type: Improvement
> Components: Amdatu Testing - Performance, Amdatu Web
> Affects Versions: 0.2.1
> Reporter: Bram de Kruijff
> Fix For: 0.2.1
>
>
> The performance test framework hasn't been used in a while and currently
> fails at startup. Furthermore, it was designed to handle one big amdatu zip
> and there are no platform tests. This issue should cover getting the thing up
> and running and implementing some basic platform tests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
