Re: [controller-dev] OpenDaylight Base Edition system test

Baohua Yang <yangbaohua@...>

Hi, luis and other team members
I guess both can be taken simultaneously.
IMHO, the test code can be manually utilized for individual testing, or can be triggered by the robot framework.
For the first step, the test team members can leverage the code to help manual test, especially in avoiding checking the human-unreadable API responses.
Once it is robust enough, we can consider to integrate it with the robot framework.
The python-based code might not be the only test framework, but we try to make it flexible and easy enough to accelerate the test processing automatically.
How do you guys think? :)

On Thu, Oct 31, 2013 at 1:31 AM, Luis Gomez <luis.gomez@...> wrote:

Hi Baohua and Denghui, thanks very much for your effort. All this reminds me we need to start looking at what will be the development framework for system test. One idea would be to store all the test code in our integration git repository and then trigger a system test whenever there is a change in the test code (same as people are doing with Java test), the flow could be like:


But instead (or in addition) of Jenkins Verification and Merge build jobs, we can have Jenkins calling Robot (with doctest) to execute system test in the test VMs to verify test code and report the result back to Jenkins to proceed with flow.


What do you think?



From: Baohua Yang [mailto:yangbaohua@...]
Sent: Wednesday, October 30, 2013 2:34 AM
To: Liguangpeng (Roc, IPTechnologyResearchDept&HW)
Cc: Luis Gomez; discuss@...; dev (controller-dev@...); integration-dev@...

Subject: Re: [controller-dev] [integration-dev] OpenDaylight Base Edition system test


Hi, team

     Denghui and I have prepared some python-based CSIT tool at

     The idea is to use doctest to trigger automatic test result validation with pre-set content.

     It may be used individual or integrated with the robot framework.

     Now I've finished a switch nodes list example on the switchmanager module for the base release.

     Anyone is welcome to review, debug, pull, comments, any type of make contribution.



On Wed, Oct 30, 2013 at 9:32 AM, Baohua Yang <yangbaohua@...> wrote:

Yes, and we should also provide a standard reference test topology for most test cases.

Guangpeng, we can discuss this more thoroughly at tomorrow's meeting.


On Tue, Oct 29, 2013 at 9:48 PM, Liguangpeng (Roc, IPTechnologyResearchDept&HW) <> wrote:

Another reason. We may have different request bodies in different environments. So, saving the REST sessions in environment is a good choice. J


From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Tuesday, October 29, 2013 10:12 AM
To: Baohua Yang

Subject: Re: [controller-dev] [integration-dev] OpenDaylight Base Edition system test


Hi Baohua and others, I have most of the PUT bodies saved in the Firefox REST client. I did not put them in the wiki because they occupy a lot of space.





From: Baohua Yang [mailto:yangbaohua@...]
Sent: Monday, October 28, 2013 7:08 PM
To: Luis Gomez
Cc: discuss@...; dev (controller-dev@...); integration-dev@...
Subject: Re: [integration-dev] OpenDaylight Base Edition system test


Thanks luis!

We may add more examples on the special items, like link body, host body, flowspec body part, to make it easier for users.


Denghui will update the prerequisite part to add more instructions on the test tool running soon.


On Tue, Oct 29, 2013 at 7:20 AM, Luis Gomez <luis.gomez@...> wrote:

Hi all,


We, the Integration group, have started writing the system test plan for OpenDaylight Base edition:


Note that system test is based on current controller capabilities, we plan to expand it when new APIs (like OF1.3) get available.


Please let us know your questions, suggestions and comments around the system test.





integration-dev mailing list


Best wishes!


Best wishes!


Best wishes!

Best wishes!

Join to automatically receive all group messages.