class
ItemValidationTest
(
FunctionalTest
):
@skip
def
test_cannot_add_empty_list_items
(
self
):
[
...
]
At this point we can rerun the FTs and see they all still work:
Ran 3 tests in 11.577s
OK
That’s labouring it a little bit, and we could probably get away doing this stuff in fewer
steps, but, as I keep saying, practising the step-by-step method on the easy cases makes
it that much easier when we have a complex case.
Now we switch from a single tests file to using one for each class, and one “base” file to
contain the base class all the tests will inherit from. We’ll make four copies of
tests.py
,
naming them appropriately, and then delete the parts we don’t need from each:
$
git mv functional_tests/tests.py functional_tests/base.py
$
cp functional_tests/base.py functional_tests/test_simple_list_creation.py
$
cp functional_tests/base.py functional_tests/test_layout_and_styling.py
$
cp functional_tests/base.py functional_tests/test_list_item_validation.py
base.py
can be cut down to just the
FunctionalTest
class. We leave the helper method
on the base class, because we suspect we’re about to reuse it in our new FT:
functional_tests/base.py (ch10l003).
from
django.contrib.staticfiles.testing
import
StaticLiveServerCase
from
selenium
import
webdriver
import
sys
class
FunctionalTest
(
StaticLiveServerCase
):
@classmethod
def
setUpClass
(
cls
):
[
...
]
def
tearDownClass
(
cls
):
[
...
]
def
setUp
(
self
):
[
...
]
def
tearDown
(
self
):
[
...
]
def
check_for_row_in_list_table
(
self
,
row_text
):
[
...
]
Keeping helper methods in a base
FunctionalTest
class is one use‐
ful way of preventing duplication in FTs. Later in the book (in
Chap‐ ter 21 )we’ll use the “Page pattern”, which is related, but prefers com‐
position over inheritance.
172
|
Chapter 10: Input Validation and Test Organisation