Create a test that verifies search is working

[samselikoff]

Ideally this is high-level, and ignorant of the implementation details (like Algolia).

If we can use an acceptance test in this repo that hits the actual Algolia endpoint, that would be ideal. I'm not sure if this can run from Travis, in containers etc.

If not, we'll have to think of something else.

[rtablada]

I talked to some friends (contributors to Webdriver and Cypress) about the best way to do smoke tests for things like guide navigation and search.

Based on me saying we have elements to click on and that we don't care about cross browser testing:

If thats the case puppeteer is the lighter weigh solution I’d do that

I think in this direction the best/easiest thing to do would be to have a small node test project that is:

• Puppeteer
• Qunit

Then make it a travis container with:

• Node
• Chrome

Then run the test on cron and then possibly if we can get cross project sync working then after Ember deploys and Ember Guide deploys.

[rtablada]

I think the flow that we'd want to test is:

• Visit https://emberjs.com
• Click "Docs" in nav
• Assert dropdown shows
• Click "Guides" in dropdown
• Assert url == guides.emberjs.com
  • Maybe extra assertions on stuff loading on the page?
• Type something in search (what's something we know should be in each release for a while)
• Assert search popup shows with results

[mansona]

@rtablada while I agree that we can make a really sophisticated RUM style "real browser" test, I'm happy to have a simple acceptance test that can be run on Travis once a day 👍 in fact the once a day thing isn't really that important, if it's just part of our normal CI we should notice it pretty quickly if it breaks.

If we really want to get fancy we can add an independent "test" index so that we don't pollute the Algolia analytics, but we can add that later 😂