Open Stack

Just to add to this - Akihiro did mention the usage of @override_settings
I've seen examples of this in existing unit tests and I can implement
something 
similar. 

This will mean however that we will have the test with the default setting
and then the same test again with the override which accepts the
profile_id yes?


On 4/24/14 10:54 AM, "Abishek Subramanian (absubram)" <absubram at cisco.com>
wrote:

>Hi all, Akihiro,
>
>I wanted to get a little feedback on the issue regarding the running
>of the dashboard unit tests with the cisco n1k profiles
>(and very soon the cisco DFA profiles) and more specifically
>how to have existing network and instance unit tests run both
>with and without profiles.
>
>Currently there all tests relating to profiles are turned off
>by default. In order to run them, you need to manually go enable
>running them by changing the test/settings.py file.
>
>Based on community feedback and review comments from Akihiro, I raised
>this bug to fix this issue -
>https://bugs.launchpad.net/horizon/+bug/1229819
>I have an initial WIP review out for it as well that I'd appreciate
>feedback on.
>
>
>There are two kinds of 'profile' related tests. One set is directly
>part of the 'router' dashboard. These I have fixed via the review to now
>run always by default.
>There is another set - in existing network and instance launch unit tests.
>The issue with these tests is that the network create and nova server
>create 
>APIs will need a profile_id argument if and only if the appropriate
>neutron plugin is being used.
>
>If not, the neutron APIs will not take a profile_id argument.
>Hence, in horizon, the code checks to see if the profile_id should be
>given or not. 
>Similarly the unit tests mock this same behavior. The dilemma here is how
>to run the same unit test and hence the same portion of actual code once
>with 
>the profiles and once without.
>
>I'd appreciate any suggestions. Please let me know if there are any
>further 
>questions to clarify this problem.
>
>Regards,
>Abishek
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev