deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jvlcek <jvl...@redhat.com>
Subject Re: [PATCH] SITE: Update test recording instructions
Date Wed, 13 Mar 2013 15:13:59 GMT
On 03/13/2013 09:14 AM, Koper, Dies wrote:
> Hi Joe,
>
> Thanks, that explanation seems to match what I was thinking.
>
>> new HTTP requests will be made.Which according to my understanding is
>> the safer approach.
> Safe because of what?
> With ' :record => :new_episodes', when a fixture is accidentally deleted, it will
try to connect to the endpoint and operations will fail because of the fake credentials.
> With ' :record => :none', when a fixture is accidentally deleted, it won't try to
connect to the endpoint, rather return an error immediately?
>
> And for this benefit we need to learn a new environment variable?

I guess I like the environment variable approach because it makes the record
happening definitive. Recordings only happen when the env. var. is
defined and doesn't
require editing of the test source to change the record mode. I don't
feel the overhead
having the 1 env. var. is so intolerable.

Joe


>
> Regards,
> Dies Koper
>
>
>> -----Original Message-----
>> From: jvlcek [mailto:jvlcek@redhat.com]
>> Sent: Thursday, 14 March 2013 12:01 AM
>> To: dev@deltacloud.apache.org
>> Cc: Koper, Dies
>> Subject: Re: [PATCH] SITE: Update test recording instructions
>>
>> On 03/12/2013 07:05 PM, Koper, Dies wrote:
>>> I've been wondering something about this re-recording.
>>> In the fgcp unit tests I have ' :record => :new_episodes' in default
>> cassette options.
>>> The first time I run new tests, it does a recording. If I want to rerecord,
>> I delete the relevant fixtures and rerun.
>>> Much easier than having to remember an environment property name.
>>> Also, even with the VCR_RECORD trigger, does it automatically
>> override/delete old fixtures (especially if you've renamed or deleted
>> tests)?
>>> If there anything wrong with the way I'm doing it for fgcp that is
>> better/easier to do with the VCR_RECORD trigger?
>>> Cheers,
>>> Dies Koper
>>
>> Hey Dies,
>>
>> The |:new_episodes|record mode replays previously recordedrequests and
>> records new ones.
>>
>> see:
>> https://www.relishapp.com/vcr/vcr/v/1-6-0/docs/record-modes/new-epis
>> odes
>>
>> VCR_RECORD will toggle record mode "all", which records all requests and
>> does not
>> replay any previously recorded responds. The "none"||record mode
>> guarantees that no
>> new HTTP requests will be made.Which according to my understanding is
>> the safer approach.
>>
>> The VCR_RECORD is only an environment variable that is picked up by the
>> tests to toggle the record mode. It does not cause any source file
>> clean-up of old fixtures.
>>
>> Hope this helps!
>>   Joe
>>
>>
>>
>>
>>>> -----Original Message-----
>>>> From: David Lutterkort [mailto:lutter@redhat.com]
>>>> Sent: Wednesday, 13 March 2013 9:27 AM
>>>> To: dev@deltacloud.apache.org
>>>> Subject: Re: [PATCH] SITE: Update test recording instructions
>>>>
>>>> On Tue, 2013-03-12 at 17:39 -0400, jvlcek@redhat.com wrote:
>>>>> From: Joe VLcek <jvlcek@redhat.com>
>>>>>
>>>>> This is required to better describe recent changes
>>>>> for parameterizing recording and provider configuration
>>>>> of credentials and resources to avoid having to edit
>>>>> test source code in order to record test fixtures.
>>>>> ---
>>>>>  site/content/running-the-white-box-tests.md        | 25 ++++--
>>>>>  .../update-vcr-test-fixtures-data-example.md       | 95
>>>> ++++++----------------
>>>>>  site/output/running-the-white-box-tests.html       | 25 ++++--
>>>>>  .../update-vcr-test-fixtures-data-example.html     | 94
>>>> ++++++---------------
>>>>>  4 files changed, 84 insertions(+), 155 deletions(-)
>>>>> diff --git a/site/content/update-vcr-test-fixtures-data-example.md
>>>> b/site/content/update-vcr-test-fixtures-data-example.md
>>>>> index 2f8074a..ef64573 100644
>>>>> --- a/site/content/update-vcr-test-fixtures-data-example.md
>>>>> +++ b/site/content/update-vcr-test-fixtures-data-example.md
>>>>> @@ -29,62 +29,44 @@ More information can be found on the past recording
>>>> of the
>>>>>  <ol>
>>>>>    <li>
>>>>>      <p> Create ${HOME}/.deltacloud/config</p>
>>>>> +    <br>
>>>>> +    <p> Create the deltacloud config file:
>>>> ${HOME}/.deltacloud/config</p>
>>>>> +    to contain the credentials and provider resource UUIDs</p>
>>>>>
>>>>>      <pre>
>>>>>      rhevm:
>>>>>        user:     'admin@internal'
>>>>>        password: 'localpassword'
>>>>> -      provider:
>>>> 'https://16.1.1.3/api;b9bb11c2-f397-4f41-a57b-7ac15a894779'
>>>>> -    mock:
>>>>> -      user: mockuser
>>>>> -      password: mockpassword
>>>>> -      provider: compute
>>>>> +      provider: 'https://rhevm.example.com/api'
>>>>> +      preferred:
>>>>> +        datacenter: UUID of a datacenter/realm
>>>>> +        vm: UUID of an existing instance
>>>>> +        template: UUID of an existing template/image
>>>> Why did you remove mock here ? It was a good way to show people how
>> to
>>>> add credentials for additional drivers. It's also useful when you run
>>>> 'deltacloudd -c'
>>>>
>>>>> -    <p>Modify the test source to have the realm, instance, image
>> &
>>>> provider
>>>>> -       for a live cloud provider.</p>
>>>>> +    <p>Set the VCR record mode to <i>all</i></p>
>>>>> +    <br>
>>>>> +    <p> Note: This does not cause <i>all</i> tests
to be recorded.
>>>>> +    It instructs VCR to record new fixtures data for the test to
>>>>> +    be run in the next step.</p>
>>>> Can you modify the other tests to use VCR_RECORD to trigger recording ?
>>>>
>>>>>      <p>Remove ${HOME}/.deltacloud/config</p>
>>>> This is not needed anymore - it doesn't matter whether you have that
>>>> file in place or not during playback.
>>>>
>>>>>    <li>
>>>>> -    <p>Remove trailing white space from the fixtures YAML files.</p>
>>>>> +    <p>Deal sith trailing white space from the fixtures YAML
>> files.</p>
>>>> Tyop, and I don't think we need this section. It's fine to check the
>>>> YAML files in with trailing ws.
>>>>
>>>> David
>>>>
>>>>


Mime
View raw message