incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Re: [Discuss] Integration test
Date Mon, 07 Jan 2013 23:13:32 GMT
Hi Edison,

So, are you looking at something like this?:

* 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?)

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?

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

Obviously I'm new to CloudStack.  Can someone fill me in on how Spring is
leveraged within CloudStack?


On Mon, Jan 7, 2013 at 3:11 PM, Edison Su <> 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
> .
>         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.*
o: 303.746.7302
Advancing the way the world uses the

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message