199 / 478
Often, however, the best ideas for how to refactor code don’t occur to you straight away.
They may occur to you days, weeks, even months after you wrote a piece of code, when
you’re working on something totally unrelated and you happen to see some old code
again with fresh eyes. But if you’re halfway through something else, should you stop to
refactor the old code?
The answer is that it depends. In the case at the beginning of the chapter, we haven’t
even started writing our new code. We know we are in a working state, so we can justify
putting a skip on our newFT (to get back to fully passing tests) and do a bit of refactoring
straight away.
Later in the chapter we’ll spot other bits of code we want to alter. In those cases, rather
than taking the risk of refactoring an application that’s not in a working state, we’ll make
a note of the thing we want to change on our scratchpad and wait until we’re back to a
fully passing test suite before refactoring.
Splitting Functional Tests out into Many Files
We start putting each test into its own class, still in the same file:
functional_tests/tests.py (ch10l002).
class
FunctionalTest
(
StaticLiveServerCase
):
@classmethod
def
setUpClass
(
cls
):
[
...
]
@classmethod
def
tearDownClass
(
cls
):
[
...
]
def
setUp
(
self
):
[
...
]
def
tearDown
(
self
):
[
...
]
def
check_for_row_in_list_table
(
self
,
row_text
):
[
...
]
class
NewVisitorTest
(
FunctionalTest
):
def
test_can_start_a_list_and_retrieve_it_later
(
self
):
[
...
]
class
LayoutAndStylingTest
(
FunctionalTest
):
def
test_layout_and_styling
(
self
):
[
...
]
Validation FT: Preventing Blank Items
|
171