Add some tests

[cristianoc72]

Starting to use this awesome library, I decided to contribute writing some tests.

Thanks to Guzzle mock system we can easily test our library in isolation, without real calls to the Dropbox api.
I included the needed methods in src/TestCase.php. Each test class should extend it, to have the mock system already initialized. In this way, we can test if our library send correct requests and if correctly manages the responses, as you can see in tests/DropboxTest.php.

By now, I'm submitting this small PR, testing only Dropbox::getMetadata method. If you like this approach, I can go on with all the other tests.

[kunalvarma05]

There's a tiny typo: testGettMetadataOnFolder must be testGetMetadataOnFolder.

[kunalvarma05]

We can delegate the creation of dummy JSON responses for the request to a separate class(es). Thoughts?

[cristianoc72]

Great idea, test cases could be clearer. Maybe, we could have some traits, to do something like this:

namespace Util 
{
    trait ResponsesForDropbox
    {
        public function getResponseForBlaBlaTest()
        {
             return new Response(......);
        }
    }
}

class DropboxTest extends TestCase
{
    use Util\ResponsesForDropbox;

    public function blaBlaTest()
    {
        $response = $this->getResponseForBlaBlaTest();
        ..............................
    }
}

[kunalvarma05]

Neat. This makes sense 👌

[kunalvarma05]

Almost all the API methods that we're gonna test, will require us to assert the correctness of the URI for that endpoint. Can we delegate this to a separate trait/method, so that we only have to pass the endpoint (/files/get_metadata in this case)?

Also, the getBasePath() on the DropboxClient class's object can be used instead of https://api.dropboxapi.com/2 for RPC endpoints (like getMetadata()) and getContentPath() for Content-Upload/Download endpoints (like download()).

Thoughts?

[cristianoc72]

Sure! We can write a method (into TestCase class) to test the request in one single call, i.e.:

public function testDropbox()
{
    ...........
    $this->testRequest('/url/to/test');
}

About the use of getBasePath() and getContenPath() functions , I'm not sure about it: hardcoding urls in such tests is considered a best practice.

[kunalvarma05]

Interesting. Any reason why this is considered a best practice?

[cristianoc72]

Well, I've read more carefully some documents about testing and, I'm sorry, but it was my fault: harcoding urls is not ALWAYS a best practice. It is in those cases where an error in generating paths can propagate through the code, i.e. when I'm working on the route system of a framework.
In our case we can use the functions you suggested.
I'll fix it this evening.

[kunalvarma05]

No problem.

It is in those cases where an error in generating paths can propagate through the code, i.e. when I'm working on the route system of a framework.

FWIW, I learnt something new 👆 apparently :)