Traceback (most recent call last):
File "functional_tests.py", line 18, in
test_can_start_a_list_and_retrieve_it_later
self.assertIn('To-Do', self.browser.title)
AssertionError: 'To-Do' not found in 'Welcome to Django'
---------------------------------------------------------------------
Ran 1 test in 1.747s
FAILED (failures=1)
That’s a bit nicer isn’t it? It tidied up our Firefox window, it gives us a nicely formatted
report of how many tests were run and how many failed, and the
assertIn
has given
us a helpful error message with useful debugging info. Bonzer!
Implicit waits
There’s one more thing to do at this stage: add an
implicitly_wait
in the
setUp
:
functional_tests.py.
[
...
]
def
setUp
(
self
):
self
.
browser
=
webdriver
.
Firefox
()
self
.
browser
.
implicitly_wait
(
3
)
def
tearDown
(
self
):
[
...
]
This is a standard trope in Selenium tests. Selenium is reasonably good at waiting for
pages to complete loading before it tries to do anything, but it’s not perfect. The
implic
itly_wait
tells it to wait a few seconds if it needs to. When asked to find something on
the page, Selenium will now wait up to three seconds for it to appear.
Don’t rely on
implicitly_wait
; it won’t work for every use case. It
will do its job while our app is still simple, but as we’ll see in
Part III(eg, in
Chapter 15and
Chapter 20 ), you’ll want to build more so‐
phisticated,
explicit
wait algorithms into your tests once your app
gets beyond a certain level of complexity.
Commit
This is a good point to do a commit; it’s a nicely self-contained change. We’ve expanded
our functional test to include comments that describe the task we’re setting ourselves,
our minimum viable to-do list. We’ve also rewritten it to use the Python
unittest
module and its various testing helper functions.
Do a
git status
—that should assure you that the only file that has changed is
func‐
tional_tests.py
. Then do a
git diff
, which shows you the difference between the last
18
|
Chapter 2: Extending Our Functional Test Using the unittest Module