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

Pipes - Kimberley Zell - Api-Muncher #38

Open
wants to merge 26 commits into
base: master
Choose a base branch
from

Conversation

kimpossible1
Copy link

API Muncher

Congratulations! You're submitting your assignment!

Comprehension Questions

Question Answer
How did you go about exploring the Edamam API, how did you try querying the API? I used Postman and then the console to check the parsed response for my expectations
Describe your API Wrapper. How did you decide on the methods you created? I followed along with the requirements. I created a self.search method that returns a list of recipes according to entry from user. I also made a self.find method that gets a specific recipe from the api, based on the uri of the recipe. I have a helper method in private methods that creates the individual recipe instances with only the data I have listed.
Describe an edge case or failure case test you wrote for your API Wrapper. I checked that it returns nil if a recipe uri is invalid or not found.
Explain how VCR aids in testing an API. It records data from a test query so that future tests on same query can use that saved information rather than query the API repeatedly
What is the Heroku URL of your deployed application? https://recipe-monster.herokuapp.com/

@droberts-sea
Copy link

API Muncher

What We're Looking For

Feature Feedback
Core Requirements
Git hygiene yes
Comprehension questions yes
General
Rails fundamentals (RESTful routing, use of named paths) yes
Semantic HTML yes
Errors are reported to the user yes
API Wrapper to handle the API requests yes
Controller testing mostly - see inline comments
Lib testing mostly - see inline comments
Search Functionality yes
List Functionality yes
Show individual item functionality (link to original recipe opens in new tab) yes
Styling
Foundation Styling for responsive layout yes
List View shows 10 items at a time/pagination yes
The app is styled to create an attractive user interface yes - In some places the text was hard to read on top of the background. One strategy to get around this is to make the element containing the text slightly opaque to give better contrast.
API Features
The App attributes Edaman yes
The VCR casettes do not contain the API key yes
External Resources
Link to deployed app on Heroku yes
Overall Good job overall! The core functionality of the app (querying an API and turning the results into a webpage) works great. Error handling isn't as fine-grained as I might like and (as with most software projects) there's some room to expand your test coverage, but in general I'm quite happy with this submission. Keep up the hard work!

</header>

<section class="main">
<% if flash[:message] %>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why <section class="main"> instead of <main>?

response = self.parse_response(HTTParty.get(url))
recipe_list = []

if response.is_a?(Hash) && response["hits"]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like these checks - they'll definitely keep your program form trying to read data that doesn't exist.

One thing I'm noticing: this method doesn't have any way to distinguish between an error response (for example because of bad API keys) and a success response with no hits.

Since one of these cases is a programer error and the other indicates the user did something wrong, I would argue that they ought to be handled differently. In order to do so, this method would have to return some more information.

end

it "returns a collection of recipes when from parameter is not given" do
VCR.use_cassette("recipes") do

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that you exercise both these cases around the from parameter. Other cases I'd be interested in seeing here:

  1. What if the search returns no results (for example, a search for "dfaljdfalflaksjflaksj")?
  2. What if the paging parameters are invalid (negative number, etc)?
  3. What if the paging parameters take you past the end of the available search results?

The first of those is covered by your lib tests below, but it's still important to verify the controller does the right thing in this situation.


it "returns not found when an invalid uri is given" do
VCR.use_cassette("bad_uri_recipe") do
get recipes_path, params: { id: "http://www.edamam.com/ontologies/edamam.owl#recipe_421df807e21c65c842ec62870604" } #bad uri

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good failure test

end

VCR.use_cassette("recipe") do
recipe = RecipeApiWrapper.find(uri)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the pattern of this test - using real search results to seed the call to find.

result.must_be_kind_of Array
result.must_be_empty
end
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see some testing around the second parameter to search here.

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

Successfully merging this pull request may close these issues.

2 participants