Add basic E2E Cypress Tests

[mrWh1te]

• Books
  • view them
  • select a book to add to cart
• Cart
  • drop-down interactions
  • add/remove items
• Checkout
  • validation testing on button for disabled
• Added cypress-commands for text()
• Setup TypeScript with imports
  • using @cypress/webpack-preprocessor and ts-loader

Covers the main "business" logic in viewing books, adding books to cart and checking them out

• replace http-server with spa-http-server for e2e tests that visit() spa routes ie /checkout
• stub the OpenLibrary.org API response

Future:
We should create an Integration test so we can be notified when OpenLibrary.org's API response structure changes
Added a basic integration test that checks to see if the response is JSON. In the future, the tests need to be expanded upon based on the structure of the JSON returned (make sure there is title, cover, the correct structure, etc. for which this app depends on)

However, as of writing this, openlibrary.org is down, so we'll have to wait.

[mrWh1te]

With the recent commit, our E2E tests are running faster because:

1. We are no longer waiting for OpenLibrary.org's API to respond, given we've stubbed it out
2. The stubbed out response data has lots of data omitted (ie subject_places, subjects, etc), including the important cover for every book's images

So we're no longer waiting for the API to resolve, or for images to load. I updated the code with ? on cover where missing so it won't error when there are no cover images to src in an img.

I ran into an issue with both. It just made it easier to stub out the response and take control that way

1. I believe we hit a DOS limit and basically got black-listed because these tests kept requesting the Images over and over again. It got to a point where no images were loading in the tests, but were fine outside
2. The API response takes a while, since we're requesting a lot of vertical data on a bunch of books. It's not the ideal setup, I've contemplated changing the way we interact with this API by selecting only a few books per request, instead of them all in 1 request, to try and make the initial data load faster, but I'm on the fence about building a backend for this project so if I do, then I'll switch over to that.

That said, this opens up a hole in our testing coverage. We now need an Integration Test to basically insure our integration with OpenLibrary.org's API. That way we can know through CI when OpenLibrary.org introduces a change to their API that breaks our system.

We could use cypress.request() to mock a network request to OpenLibrary.org to then assert the structure of its response to match our needs....

[mrWh1te]

so the branch build is passing, but the pr build (branch merged into master then tests ran) is failing

It's for the same reason as the past few. mat-card the element, is of (0, 0)px even though, in this context (inside BookUi), there is now a span that displays the id of the Book therefore giving some kind of dimension to the mat-card parent element.

I'm not sure

[mrWh1te]

About this bug I've been working on, clicking something with 0 width and 0 height... is a rendering related issue

The solution I applied comes from here: cypress-io/cypress#695 (comment)
The relevant issue is being tracked here: cypress-io/cypress#696

But that thread, never-the-less, is important to follow in regards to rendering stuff that is API data dependent (since as that API resolves, it triggers a change detection which causes a new draw and possibly cypress is clicking while the draw is occurring or before)