Initial API testing lesson.

[linkonsat]

Because

This lesson adds the initial draft of the API testing lesson.

This PR

This PR adds the API testing lesson to the curriculum. One important thing to note is that the other lessons cover a lot of prerequisite knowledge such as knowing about factory-bot. As such this lesson is a little bit shorter than the other ones.

Issue

Closes #24492

Additional Information

Pull Request Requirements

• [ ] I have thoroughly read and understand The Odin Project Contributing Guide
• [ ] The title of this PR follows the location of change: brief description of change format, e.g. Intro to HTML and CSS lesson: Fix link text
• [ ] The Because section summarizes the reason for this PR
• [ ] The This PR section has a bullet point list describing the changes in this PR
• [ ] If this PR addresses an open issue, it is linked in the Issue section
• [ ] If any lesson files are included in this PR, they have been previewed with the Markdown preview tool to ensure it is formatted correctly
• [ ] If any lesson files are included in this PR, they follow the Layout Style Guide

[rlmoser99]

Can you share the reasons behind needing an API testing lesson? I am struggling to see the need for this lesson because in the Rails section we don't have people make their own rails API project.

[linkonsat]

I'll have to make a few tweaks to this lesson I just realized. That said I have been thinking it over and that is a fair point of criticism. From my understanding it's important to test requests to ensure they work properly and give the expected results, but I do think that is a pretty fair point that we don't have an API project and it may go against the flow of the course structure. to have a lesson that isn't incorporated into a project. So i'm not against dropping it as this brings up a solid point against it. It could be better suited as part of an API standalone module after the rails content now that i'm thinking about it as well. What's your thoughts on that? @rlmoser99

[rlmoser99]

@linkonsat I've been thinking about this and wonder if we should ask the rails-path-maintainers about this lesson? I lean towards having it when we add content on creating a rails API, but I'd feel much more confident of this decision if more people weighed in on it.

[linkonsat]

Sure, I wouldn't mind asking everyone first.

[KevinMulhern]

Sorry, this is my bad. I remember calling this API testing back when we were brain storming these lessons. My thinking at that time was a lesson that taught request specs with VCR to test third party library API's like we have with the Flicker project.

I agree with Chook, a more general request specs lesson would better slot into the current course. Although theres a very good argument as to wether we should skip teaching request spec in the absence of traditional Rails API lessons.

[ChargrilledChook]

@KevinMulhern I'm partial to that argument and think the bulk of our content should be model and system feature specs.

That said I think Jason's content can often be very opinionated. It's not that I necessarily disagree in this particular case, more about trying to keep tone neutral if that makes sense

[linkonsat]

@KevinMulhern I think that would be a bit of a better fit for the standalone section. I was pondering it for a bit and maybe testing third party api libraries would be good for before the flicker project itself. That said it sounds like the conversation is leaning more towards having this as covering the generic area of testing requests, integration, the different responses etc.

@ChargrilledChook no worries. I think this discussion helps with setting the tone of what needs to be changed. All critiques are welcome. If i'm understanding right overall, it's a bit to narrow and needs to cover more stuff in the generic area of testing requests and so on.

[linkonsat]

Sorry, this took a bit longer than expected. That said I ultimately did decide it would be better to just have it be an integration test. As it seems like that would be the next type of test after unit/model. Took in your input @ChargrilledChook to cover those other things you mentioned. I did wrap in requests more so by as having it as something you can look for in your tests as well. Interested in what yall think!