Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make issues for each of the api facets #2

Open
solutionexchange opened this issue Dec 21, 2010 · 3 comments
Open

Make issues for each of the api facets #2

solutionexchange opened this issue Dec 21, 2010 · 3 comments
Labels

Comments

@solutionexchange
Copy link
Collaborator

As none of these are feature complete make an issue to track progress for each..

This is administrative reminder.

@solutionexchange
Copy link
Collaborator Author

if you want to know where to help look at failed tests of qunit.html (the homepage of the project) to see where there are gaps.

@ShellyMao
Copy link

I am looking through all the failed ones right now. Looks like there are gaps (i.e. Search tests) but perhaps some documentation could be helpful.
For example, when to use ok(false, "always fine") and how many results should be expected in each test and what each test is for. I know the test name is very self-explanatory but more documented specifications would be helpful. I am happy to start drafting for the existing tests here if you guys also think it is a good idea.

@solutionexchange
Copy link
Collaborator Author

I've been using the 'ok(false, "always fine") ' test as the first test in creating a new handler. If it remains it is acting like a flag that real tests and functionality is yet to be built. Depending on the handler some will require Open API code to get to meta data or operations on content groups and user groups that aren't exposed in any other way.

I've been aspiring to a TDD model which is write a test first. It will be a failure then write the feature to fulfill the test. The test as you suggested becomes somewhat self documenting.

I consider this early alpha stage still so I've been favoring building to get enough together to share. I think as we are opening this up it is the right time to focus on more documentation and specification.

I won't get much time until July for any focus on this. In the interim if there is a handler that you deem useful I'd suggest maybe making a thorough test set for it and use that tests to define what should be added to the wiki under API Functions
https://github.com/solutionexchange/DSaaS/wiki/REST-API-Functions

We could probably use a post on practices for collaboration at some point but I don't want to dictate anything to a community that has yet to form around this API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant