Create tests for Bitly link portion

[siruguri]

I can do this - I assume I'd add maybe another model for storing a Post's bitly links, and updating a Post body would cause possibly multiple records to be generated for a Post?

An alternate implementation would be to just replace URLs in a Post body with the corresponding bitly link and just not worry about storing the initial URL, thereby making Bitly the source of ground truth for the target URLs. Any preferences?

[akanshmurthy]

Thanks. The 2nd one would be the preference. Basically, you can imagine that within a create post page, there is a section where the user can enter in a URL to get the shortened version. The shortened version is not actually stored anywhere. The user can choose to insert that into the body and save. It's almost like having Bitly exist on the web page. All you need to check for is that an API call is being made. Implementation will be left to the students. If you want to make it such that the controller create action parses the entire body and converts all URLs to Bitly links before saving, that is ok too (but more work on your end).

[siruguri]

Ah, so it's a Javascript test, then, not a Rails test... Or would the flow be to enter URL, click Shorten, get back page with existing post title and body along with short URL?

"a section where the user can enter in a URL to get the shortened version" is not clear basically - is that shortened version obtained via XmlHttpRequest, or a full post/render loop?

Also, I thought the idea was that we are writing working code but broken tests but your comment above implies the other way round, is that right?

On Mon, Oct 31, 2016 at 10:06 PM, Akansh Murthy notifications@github.com wrote:

Thanks. The 2nd one would be the preference. Basically, you can imagine that within a create post page, there is a section where the user can enter in a URL to get the shortened version. The shortened version is not actually stored anywhere. The user can choose to insert that into the body and save. It's almost like having Bitly exist on the web page. All you need to check for is that an API call is being made. Implementation will be left to the students. If you want to make it such that the controller create action parses the entire body and converts all URLs to Bitly links before saving, that is ok too (but more work on your end).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/akanshmurthy/railsbridge-hackathon/issues/5#issuecomment-257489747, or mute the thread https://github.com/notifications/unsubscribe-auth/AACezYiJ6bX-0dA2BqXsaU_x0T80sNxhks5q5sjfgaJpZM4KeXWn .

[akanshmurthy]

Well, you could have a helper function in a posts_helper file that is called in the new view of the new.html.erb for a post, no? Presumably, there's no additional action being taken by the user until the URL is returned (which should be pretty fast) so no need for AJAX or asynchronous calls.

Yes, I believe we discussed this on the call; we are writing functional tests for functional code (since all the code is functional except for the API code, which is nonexistent since we are leaving it up to the students to decide on the implementation) and breaking it later once everything is checked in.

[siruguri]

I'm missing sth ... if I enter long URL l in the browser, I somehow have to get Bitly url b back in the browser.

So something has to trigger the Bitly API call. Is it a form on a separate "Bitly page" of the app? If the form is on the same page as views/posts/new, a POST on that page will by default lose data entered into other input fields.

It's not the implementation I'm asking about - it's the user flow I'm confused about.

On Mon, Oct 31, 2016 at 10:19 PM, Akansh Murthy notifications@github.com wrote:

Well, you could have a helper function in a posts_helper file that is called in the new view of the new.html.erb for a post, no? Presumably, there's no additional action being taken by the user until the URL is returned (which should be pretty fast) so no need for AJAX or asynchronous calls.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/akanshmurthy/railsbridge-hackathon/issues/5#issuecomment-257490936, or mute the thread https://github.com/notifications/unsubscribe-auth/AACezXZxm5mOaV-UxdhGGScWe8Ec9BV5ks5q5svygaJpZM4KeXWn .

[akanshmurthy]

Good question. I believe we can leave the actual implementation up to the student (a Bitly partial template with a form on the new post page could be a possibility). We just want to check for outgoing API calls and not constrain the design if possible.

[siruguri]

Ok, tell you what: how about the test is:

"When I save a new post, the app makes a Bitly api call, and the rendered page shows me a bitly URL (whose intended target is the page itself but naturally this cannot be tested.)"

works?

On Mon, Oct 31, 2016 at 10:06 PM, Akansh Murthy notifications@github.com wrote:

Thanks. The 2nd one would be the preference. Basically, you can imagine that within a create post page, there is a section where the user can enter in a URL to get the shortened version. The shortened version is not actually stored anywhere. The user can choose to insert that into the body and save. It's almost like having Bitly exist on the web page. All you need to check for is that an API call is being made. Implementation will be left to the students. If you want to make it such that the controller create action parses the entire body and converts all URLs to Bitly links before saving, that is ok too (but more work on your end).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/akanshmurthy/railsbridge-hackathon/issues/5#issuecomment-257489747, or mute the thread https://github.com/notifications/unsubscribe-auth/AACezYiJ6bX-0dA2BqXsaU_x0T80sNxhks5q5sjfgaJpZM4KeXWn .

[akanshmurthy]

Sounds good. We can always iterate once we have something working.

[siruguri]

Can someone review the above commit and let me know what you think? It has a test that needs code to pass; it fixes up .gitignore a bit; and adds a User fixture.

I'll also submit a PR if you prefer reviews that way.