Set content type headers and POST values to an HTML form using Chai HTTP.
- [Instructor] The reservation form has, well, a form, so let's functionally test that next. Switch back to Atom, and make sure that test, functional, and reservations.js is open. Navigate to after the get and add a new context for post, so context post, which takes a function. Our first assertion is that it should accept a valid reservation request, which takes a function with a done callback.
Chai will request the app. Instead of get, we're going to post to forward slash reservations. Since this is a form submission, set the content type to application forward slash x-www-form-urlencoded. For the form submission itself, we can .send an object, which Chai HTTP will unpack for us.
This dummy object is the same we've used elsewhere, so date of 2017/06/10. The time is 06:02AM, the party is size four, the name is family, the email is email@example.com. Finally, .end to get the callback of the error and response.
The response text, so res.text, should contain "Thanks, your booking request number," and we're going to specify the hard coded ID, so 1349. The status should also be 200, so res should have status 200. When complete, use the callback, so done and error, which should be empty.
Close out the semicolons. Now let's test the inverse. Copy and paste the first test, then new line, paste, so instead it should reject an invalid reservation request. For the party size, let's specify something obviously incorrect. So the party size is going to be bananas. The result text will change as well to contain the error message.
Instead of thanks, let's do "Sorry, there was a problem with your booking request." The status is 400, not 200, and there was an error so do not pass it to done. Save the changes, then open up a terminal. Let's check the coverage now. Using NPM, run the coverage script. Press return.
If we open it up just a little bit more, much closer to that elusive 100%. Want to parse the HTML properly instead of just searching for text? Check out cheerio.js.org for an implementation of core jQery without the browser cruft. Speaking of that 100% coverage, should we attempt it? What's the worst that could happen?
- What is code quality?
- Testing and code quality fundamentals
- Coding conventions and standards
- Creating and enforcing coding standards
- Unit, integration, and functional testing
- Test-driven development test specificatons
- Behavior-driven development test specifications
- Finding errors with linting
- Extending an ESLint shareable config
- Validating correctness with unit testing
- Replacing and inspecting with stubs, spies, and mocks
- Code coverage and why it matters
- Coverage with continuous integration