Merge lp://qastaging/~stevanr/linaro-license-protection/production-integration-tests into lp://qastaging/~linaro-automation/linaro-license-protection/trunk

So much nicer, thanks for working on this.

Now, considering what is mostly tested, I'd suggest you add a get_content_title() method which extracts the title tag (considering you are already using BeautifulSoup, that should be easy), so the output would be nicer and even more clear, for example:

    Browsing into the android/~linaro-android/*snowball* works without asking for any license acceptance:

        >>> browser.browse_to_relative("android/")
        >>> browser.get_content_title()
        u'Index of /android'
        >>> browser.browse_to_relative("~linaro-android")
        >>> browser.get_content_title()
        u'Index of /android/~linaro-android'
        >>> browser.browse_to_relative("snowball")
        >>> browser.get_content_title()
        u'Index of /android/~linaro-android/...snowball...'

As you can see, I am also suggesting joining a few steps behind a single narrative. I'd suggest you do the same for the target/product/* step as well.

I like all the other improvements (DoctestProductionBrowser(host), get_license() call etc).

It would still be nicer to print out the headers one-per-line instead of as a dict:

        >>> print browser.get_header_when_redirected()
        Content-Length: ...
        Location: http://snapshots.../boot.tar.bz2
        Content-Type: application/x-bzip2
        ...

Also note that there is no guarantee in what order headers will be returned, and this test might easily break, so I suggest get_headers_when_redirected sorts them by name before returning a string with one header per line.

Uhm, make those browse_to_relative browse_to_next, mea culpa. :)

Also, I think we are missing one step. We need to confirm there is an 'accept' link in the license, and we want to simulate clicking it. I am not sure how best to do that, but I am sure you can figure something out (we can simply check if the URL there is absolute or relative, and then browse to it).

On 16 May 2012 11:34, Данило Шеган <email address hidden> wrote:
> Also, I think we are missing one step.  We need to confirm there is an
> 'accept' link in the license, and we want to simulate clicking it.  I am
> not sure how best to do that, but I am sure you can figure something out
> (we can simply check if the URL there is absolute or relative, and then
> browse to it).

Finding and clicking the accept link is exactly what the download
script does :-)

--
James Tunnicliffe

Right, but this is about proving that this works from a users' perspective, not that we've got code which can get through the click-through.

True, though my point was that the script emulates a user by finding
the link and following it. It may be useful in this case because it
would prove that the link exists and that clicking on it allows the
user to download the file they are expecting.

Right, understood. However, since this is supposed to be a user-readable (and repeatable) test plan, I'd rather if all the steps are clear from the actual doctest.

> True, though my point was that the script emulates a user by finding
> the link and following it. It may be useful in this case because it
> would prove that the link exists and that clicking on it allows the
> user to download the file they are expecting.

Imho, Danilo has the point, but James' script allows me to test this with get_protected_file method. It emulates a click to the accept license link and then gets the file requested. I'll use it in my browser class and that's it.

This looks good. It would be nice to test for 404 errors ending up on the same URL, but definitely not for this branch. At this time, this is more than good enough.

We'll probably want to decouple these tests from the automated tests since they need to run at different times (most of them before landing, these tests after deployment).