search

dropbox / dbxcli

A command line client for Dropbox built using the Go SDK
Other
1.05k stars 101 forks source link

Unit testing #45

Open waits opened 8 years ago

waits commented 8 years ago

Just wanted to start a discussion on unit testing, since @diwakergupta and @GrantSeltzer mentioned it and it's been on my mind as well.

Should we mock all the API responses? It'd be simpler and less fragile that way, besides the initial overhead of creating all the mocks (but those could just be a bunch of files with HTTP/JSON responses). The Dropbox API doesn't have a "test mode", anyways, so I don't see a way around this.

Should we do any integration tests? I see a small test script @diwakergupta wrote, which might be enough. It looks like it cleans up after itself too. Of course, there's always a chance of nuking your entire Dropbox when running live tests, but that's better than publishing a release with such a flaw.

Does anyone feel strongly about testing frameworks? Go already has one of the most complete testing packages I've seen in a standard library, so we might not need anything else. I've had success using just that in other projects. Ginko has some fans as well, although it's quite different and BDD-based.

diwakergupta commented 8 years ago

GoMock seems like the "official" mocking framework (https://github.com/golang/mock), but there are certainly others (e.g. testify https://github.com/stretchr/testify#mock-package)

If we have good coverage via mocks, I'm OK skipping integration tests for regular commits. I can still run the test script by hand before cutting a release. In any case, running integration tests in a CI environment like Travis has a bunch of security implications that I'd rather avoid at this point :)

grantseltzer commented 8 years ago

Hi, sorry for the late response. Thanks for bringing this up @waits.

So the complication that I see in unit testing comes from the fact that dbxcli is interacting with the dropbox api, so any unit testing has to be careful to be testing dbxcli, and not be affected by problems with the sdk/api.

I'm under the assumption that the api will be kept solid so we don't have to worry about changes on that end. With that in mind, I think mocking API responses is the way to go. I've never used GoMock but it seems good (Although documentation is light).

I think we should come up with a roadmap on how to proceed, Identifying what needs tests the most. Possibly commands with the most 3rd party dependencies? I also think once a couple tests/mocks are written it becomes easier and easier to write the rest.

As for integration tests, it seems less necessary and as @diwakergupta said, has security implications.

diwakergupta commented 7 years ago

@waits @GrantSeltzer are either of you interesting in working on this? :)

grantseltzer commented 7 years ago

@diwakergupta Certainly, but when I have more time post graduation. I think it'd be really useful if we make a milestone for acceptable amount of testing. Under that if we make issues for individual files and important functions then it would make it easier to attract contributors from the community :D