|
| 1 | +# Part 3: Writing assertions |
| 2 | + |
| 3 | +Part 3 of the workshop focuses on making assertions about the result page after performing a search. |
| 4 | +Waiting becomes a much bigger concern for these steps, but Playwright makes it easy. |
| 5 | + |
| 6 | + |
| 7 | +## Checking the search field |
| 8 | + |
| 9 | +After performing a search, our test case must check three things on the result page. |
| 10 | +According to the step, "Then the search result query is the phrase", |
| 11 | +the first thing to check is that the search input field at the top of the result page contains the search phrase. |
| 12 | + |
| 13 | +Here's the inspection panel for the search input element on the result page: |
| 14 | + |
| 15 | + |
| 16 | + |
| 17 | +This element also has an ID, |
| 18 | +so we can use the `#search_form_input` selector to uniquely identify it. |
| 19 | + |
| 20 | +To get the textual value inside this input element, |
| 21 | +you might think that we should use the |
| 22 | +[`inner_text`](https://playwright.dev/python/docs/api/class-page#page-inner-text) method |
| 23 | +or the [`text_content`](https://playwright.dev/python/docs/api/class-page#page-text-content) method. |
| 24 | +However, neither of these are correct. |
| 25 | +To get the value of an input element, you need to get its `value` attribute. |
| 26 | +Thankfully, Playwright provides a convenient method named |
| 27 | +[`input_value`](https://playwright.dev/python/docs/api/class-page#page-input-value) to get this. |
| 28 | + |
| 29 | +Add the following line to the test case: |
| 30 | + |
| 31 | +```python |
| 32 | + assert 'panda' == page.input_value('#search_form_input') |
| 33 | +``` |
| 34 | + |
| 35 | +This line will get the input value from the target element and assert that it is equal to the original search phrase. |
| 36 | + |
| 37 | +The full test case should now look like this: |
| 38 | + |
| 39 | +```python |
| 40 | +def test_basic_duckduckgo_search(page): |
| 41 | + |
| 42 | + # Given the DuckDuckGo home page is displayed |
| 43 | + page.goto('https://www.duckduckgo.com') |
| 44 | + |
| 45 | + # When the user searches for a phrase |
| 46 | + page.fill('#search_form_input_homepage', 'panda') |
| 47 | + page.click('#search_button_homepage') |
| 48 | + |
| 49 | + # Then the search result query is the phrase |
| 50 | + assert 'panda' == page.input_value('#search_form_input') |
| 51 | + |
| 52 | + # And the search result links pertain to the phrase |
| 53 | + # And the search result title contains the phrase |
| 54 | + pass |
| 55 | +``` |
| 56 | + |
| 57 | +Hold on, do we have a race condition here? |
| 58 | +After calling `page.click(...)`, the browser will load the result page, |
| 59 | +but elements on the result page need time to be ready for interaction. |
| 60 | +Our test does nothing explicit to wait for the result page to load before trying to interact with the search input element. |
| 61 | +Is this a problem? |
| 62 | + |
| 63 | +Thankfully, in this case, there is no problem. |
| 64 | +Playwright automatically waits for elements to be ready before interacting with them. |
| 65 | +So, even though the test does not perform any *explicit* waiting for the result page, |
| 66 | +the `input_value` method performs *implicit* waiting for the element to be ready. |
| 67 | +Check the [Auto-waiting](https://playwright.dev/python/docs/actionability) page |
| 68 | +for a full list of actionability checks for each interaction. |
| 69 | + |
| 70 | +Rerun the test using the same pytest command (`python3 -m pytest tests --headed --slowmo 1000). |
| 71 | +This time, you should see the result page for a good second or two before the browser window closes. |
| 72 | +The test should still pass. |
| 73 | + |
| 74 | + |
| 75 | +## Checking the result links |
| 76 | + |
| 77 | +TBD |
| 78 | + |
| 79 | + |
| 80 | +## Checking the title |
| 81 | + |
| 82 | +TBD |
0 commit comments