> -----Original Message----- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: Monday, January 07, 2013 3:14 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [Discuss] Integration test > > Hi Edison, > > So, are you looking at something like this?:
Yes. > > * System (ex. cloud-engine - a server with a RESTful API) > * Sub-system (ex. storage) > *Component (ex. snapshot) (Maven project comes in at this level) > * Plug-in (is this a separate Maven project?) Yes, most of plugins are in separate maven project, but if the plugin itself is so simple, it's not worth to create a new project. For example, storage-volumemotion will have a lot of volume motion strategies, each strategy is an algorithm to move one volume from one place to another. If developers want to add a new volume motion strategy into the system, it's better to just write a new strategy, and put it into storage-volumemotion maven project, instead of creating a new maven project. > > Regarding integration tests, is the person who wrote the code to test > responsible for writing the integration test? If not, how do we keep track of > this? Both core component/subsystem developer and plugin developer will be responsible for integration test, as it's integration test, which will cover both component code and plugin code. For example, in storage-volume-integration-test project, it may have test cases for nfs/iscsi storage. If a new storage plugin is added, then plugin developer needs to integration write test cases for the new storage type, otherwise, the integration test suites will not test against new storage plugin. > > Also, I prefer your approach of putting one Maven project at one level (as > opposed to one huge Maven project for tests). > > I don't have a strong preference regarding JUnit or testNG. I've used JUnit > in > the past, but if testNG has a better feature set, I say let's use testNG. > > Obviously I'm new to CloudStack. Can someone fill me in on how Spring is > leveraged within CloudStack? > > Thanks! > Mike > > > On Mon, Jan 7, 2013 at 3:11 PM, Edison Su <edison...@citrix.com> wrote: > > > Hi All, > > As Cloudstack is becoming more modularized, we can start thinking > > about how to test these components. > > The organization of maven projects in cloudstack. At lowest > > level, it's a maven project. The modularized component, means a group > > of maven projects. The subsystem, means a logical group of > > components. A system, will be build on a lot of subsystems. For > > example, there will be a system called, cloud-engine, which is a > > server, provides restful API service to other systems(e.g API server). > Cloud-engine will have a set of subsystems: > > computing, storage, network etc. For each subsystem, will have a group > > of > > components: e.g. storage subsystem will include volume/image/snapshot .. > > components. For each component, will have a set of maven projects, > > for example, volume component will have a maven project, called > > storage-volume, and a lot of plugin projects, such as > > (storage-volume-plugin-solidfire, storage-volume-plugin-netapp etc). > > Based on above hierarchy, the integration test will happen at > > different levels: at component level, at subsystem level, at system > > level etc. I want to bring up the discuss about how to organize > > integration tests, and which integration test framework should we use. > > First, how to organize integration tests? The organization will be > > affected/constrained by the dependency between maven projects you > want > > to test. > > 1. Will the integration test at each level have its own > > maven project? Or we put all the integration test cases into one > > giant maven project? I'd prefer one maven project at one level, as it > > looks like more cleaner. For example, there will be a > > storage-integration-test maven project, which depends on > > storage-volume-integration-test, storage-image-integration-test, and > > so on, while storage-volume-integration-test will depend on > > storage-volume, storage-volume-plugin-solidfire, and > > storage-volume-plugin-netapp and so on. When you write test case at > > each level, you only focus on the limited area you want to test: the > > design of test case and the configuration file of each test case, > > will/can only be specific to the area. Hope it will make writing test case > easier. > > 2. Which test framework we should use? Junit or testNG? I > > was sold to testNG by its feature sets: parametrized test case, group > > test cases, running test case in parallel at different level(method, > > class etc), test case dependency etc. You can find out more > > information about testNG at > > http://kaczanowscy.pl/tomek/sites/default/files/testng_vs_junit.txt.sl > > idy_.html#(1) > > . > > But in order to integrate testNG with Spring, need a little > > bit coding. For example, may need to add a listener in testNG, to > > inject @DB annotation, and need to make sure mockito will work. I > > created a base testNG class: CloudStackTestNGBase, which can read > > configuration parameters from a testNG config xml file, setup @DB context > for each test case etc. > > > > Comments/feedback are welcome! > > > > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)*
