Implement recording of identical requests with backwards compatibility and separation of concerns.

[bwood]

Context

This PR was inspired by #161 and it fixes #132. #161 didn't quite work for our use case. Cassette::hasResponse() caused Cassette::$indexTable to be incremented resulting in non-sequential indexes and off-by-one issues.

Use case

Terminus uses phpVCR. Certain Behat tests run commands that repeatedly check the status of a task. When the task finishes its status changes from null to 'success' or 'failed'. With phpVCR 1.4.4 only the first status check request is recorded.

What has been done

I've repurposed some of the methods from #161, but I've removed Cassette::$indexTable and added an $indexTable property to Videorecorder instead. The thinking here is that $indexTable manages state and moving this responsibility to Videorecorder maintains better separation of concerns. (In fact making this change required no adjustments to existing unit tests.)

Cassette::playback():

• takes an optional $index parameter (making it possible to playback a specific index multiple times -- should such a need arise).
• assigns an index of 0 to legacy cassettes which don't have indexes for backwards compatibility.

Videorecorder::handleRequest():

• determines the current request index and passes it to Cassette:playback() using the optional parameter.
• clears the index state when a cassette is ejected or loaded.

New unit tests:

• testPlaybackOfIdenticalRequestsFromLegacyCassette() ensures proper behavior with legacy cassettes.
• testPlaybackOfIdenticalRequests() ensures proper behavior with indexed cassettes.
• Improvement to testInsertCassetteEjectExisting() ensure that Videorecorder::resetIndex()is called.

How to test

1. composer install and composer test and ensure that tests are passing.
2. Enable phpVcr and run code that makes repeated identical requests to an API endpoint. Look at the cassette and see that each request was recorded and that they are differentiated by an index: N key value at the end of the request/response recording. Play back the recording and observe that the responses are played back sequentially.

Thanks

Thanks to @dsnopek for his input!

[bwood]

@JeroenVanOort might you consider this for 1.5?

[higidi]

I used this feature successfully for more than 3 years now! Is it possible to merge it so it is available for all upcoming releases? It sucks using a forked version including that feature. :-)

[higidi]

I'll close this PR, because i rebased your version onto master. See #270