Commit Graph

11 Commits

Author SHA1 Message Date
risk danger olson
d3bc59abd5 replace .GitConfig* with .Git.* 2016-08-15 15:43:38 -06:00
Taylor Blau
d2bb91e5e0 api/locks_api: implement CurrentCommitter() 2016-06-03 09:22:19 -06:00
Taylor Blau
ec6137aacf api/lock_api: use id, force as explicit arguments 2016-05-27 15:45:02 -06:00
Taylor Blau
f5578f3de8 api: add Force option to unlock requests 2016-05-27 15:42:04 -06:00
Taylor Blau
44ac3a9b3a api{client,lifecycle}: use config.Endpoint to resolve root 2016-05-25 13:31:12 -06:00
Taylor Blau
4bf693ed64 api: http.Method{Get,Post} does not exist in Go <1.6 2016-05-24 10:50:58 -06:00
Taylor Blau
00105ac8ef api/locks: LockService documentation fixes 2016-05-24 09:27:17 -06:00
Taylor Blau
8887924fff api/{lock,schema} validate LockList against schema 2016-05-24 09:27:17 -06:00
Taylor Blau
1654834630 api/lock: implement LockService.Search 2016-05-24 09:27:16 -06:00
Taylor Blau
32c557a497 api/{lock,schema}: add lock API schemas, test against the Lock API 2016-05-24 09:27:16 -06:00
Taylor Blau
c282983235 api/schema: initial take on MethodTestCase
The initial thought here is to introduce a MethodTestCase type that
encapsulates the behavior of testing a single method in a particular given
service.

To do so, a httptest.Server is created and the schema is turned into a request
which is fired at that server. Thet MethodTestCase, of course, knows how to
respond to different requests, and the behavior of those responses is tested.

What I dislike is that we have to write three things which are mostly the same
to test any endpoint in any case on the API:
  1) a request type (Go struct)
  2) an expected response type (Go type)
  3) the actual response (a mutltline Go string, which is really just JSON)

This seems redundant, so I may explore other options for implementing this sort
of thing in the future.
2016-05-24 09:27:15 -06:00