285 / 478
2 assertions of 2 passed, 0 failed.
Here’s how we tell our settings file about the new static folder:
superlists/settings.py.
[
...
]
STATIC_ROOT
=
os
.
path
.
join
(
BASE_DIR
,
'../static'
)
STATICFILES_DIRS
=
(
os
.
path
.
join
(
BASE_DIR
,
'superlists'
,
'static'
),
)
I recommend reintroducing the
LOGGING
setting from earlier at this
point. There’s no need for an explicit test for it; our current test suite
will let us know in the unlikely event that it breaks anything. As we’ll
find out in
Chapter 17, it’ll be useful for debugging later.
And we can quickly run the layout + styling FT to check the CSS all still works:
$
python3 manage.py test functional_tests.test_layout_and_styling
[...]
OK
Next, create an app called
accounts
to hold all the code related to login. That will include
our Persona JavaScript stuff:
$
python3 manage.py startapp accounts
$
mkdir -p accounts/static/tests
That’s the housekeeping done. Now’s a good time for a commit. Then, let’s take another
look at our spiked-in javascript:
var
loginLink
=
document
.
getElementById
(
'login'
);
if
(
loginLink
) {
loginLink
.
onclick
=
function
() {
navigator
.
id
.
request
(); };
}
Mocking: Who, Why, What?
We want our login link’s on-click to be bound to a function provided by the Persona
library,
navigator.id.request
.
Now we don’t want to call the
actual
third-party function in our unit tests, because we
don’t want our unit tests popping up Persona windows all over the shop. So instead, we
are going to do what’s called “mocking it out”: creating a “fake” or “mock” implemen‐
tation of the third-party API for our tests to run against.
What we’re going to do is replace the real
navigator
object with a
fake
one that we’ve
built ourselves, one that will be able to tell us what happens to it.
JavaScript Unit Tests Involving External Components: Our First Mocks!
|
257