At least in theory, this is a utility that lets you deploy arbitrary
charms. My goal was to duplicate the previous behavior--or at least the
advertised behavior :-) .
But yeah, even beyond that, this is in service of some integration
tests. I figured searching was not a bad thing in that context.
https://codereview.appspot.com/10253055/diff/1/test/test_charm_running.py#newcode121
> test/test_charm_running.py:121: return
> driver.find_element_by_css_selector('[name=bws-search]')
> so bws-search is another key we need to make sure to not change. I
know there
> was talk of re-designing the search area of the sidebar at some point.
Please
> update it with the same notes on breaking CI if it changes.
On 2013/06/14 17:26:32, rharding wrote:
> LGTM with small notes.
https:/ /codereview. appspot. com/10253055/ diff/1/ test/test_ charm_running. py charm_running. py (right):
> File test/test_
https:/ /codereview. appspot. com/10253055/ diff/1/ test/test_ charm_running. py#newcode119 charm_running. py:119: def get_search_ box(driver) :
> test/test_
> is there any reason to go through search vs the default interesting
data
> enpoint? Just to verify that search is working?
At least in theory, this is a utility that lets you deploy arbitrary
charms. My goal was to duplicate the previous behavior--or at least the
advertised behavior :-) .
But yeah, even beyond that, this is in service of some integration
tests. I figured searching was not a bad thing in that context.
https:/ /codereview. appspot. com/10253055/ diff/1/ test/test_ charm_running. py#newcode121 charm_running. py:121: return find_element_ by_css_ selector( '[name= bws-search] ')
> test/test_
> driver.
> so bws-search is another key we need to make sure to not change. I
know there
> was talk of re-designing the search area of the sidebar at some point.
Please
> update it with the same notes on breaking CI if it changes.
Done, thanks.
https:/ /codereview. appspot. com/10253055/