158 / 478
Anyway, now we know how to collect all the static files into a single folder, where it’s
easy for a web server to find them. We’ll find out all about that, including how to test
it, in the next chapter!
For now let’s save our changes to
settings.py
:
$
git diff
# should show changes in settings.py*
$
git commit -am"set STATIC_ROOT in settings and disable admin"
A Few Things That Didn’t Make It
Inevitably this was only a whirlwind tour of styling and CSS, and there were several
topics that I’d hoped to cover in more depth that didn’t make it. Here’s a few candidates
for further study:
• Customising bootstrap with LESS
• The
{% static %}
template tag, for more DRY and less hard-coded URLs
• Client-side packaging tools, like bower
Recap: On Testing Design and Layout
The short answer is: you shouldn’t write tests for design and layout. It’s too much like
testing a constant, and any tests you write are likely to be brittle.
With that said, the
implementation
of design and layout involves something quite tricky:
CSS and static files. As a result, it is valuable to have some kind of minimal “smoke test”
which checks that your static files and CSS are working. As we’ll see in the next chapter,
it can help pick up problems when you deploy your code to production.
Similarly, if a particular piece of styling required a lot of client-side JavaScript code to
get it to work (dynamic resizing is one I’ve spent a bit of time on), you’ll definitely want
some tests for that.
So be aware that this is a dangerous area. Try and write the minimal tests that will give
you confidence that your design and layout is working, without testing
what
it actually
is. Try and leave yourself in a position where you can freely make changes to the design
and layout, without having to go back and adjust tests all the time.
130
|
Chapter 7: Prettification: Layout and Styling, and What to Test About It