Permalink
Browse files

Shannon feedback: fix tests.py, broken images, "development" server.

  • Loading branch information...
1 parent a05a7bf commit 1e963b11a91199f120631753a8826bf9de273211 @hjwp committed Sep 27, 2012
Showing with 64 additions and 51 deletions.
  1. +2 −2 talk_italian.rst
  2. +0 −3 tdd-feedback.txt
  3. +14 −14 tutorial01.rst
  4. +2 −2 tutorial02.rst
  5. +3 −3 tutorial03.rst
  6. +1 −1 tutorial04.rst
  7. +3 −3 tutorial05.rst
  8. +39 −23 workshop.rst
View
4 talk_italian.rst
@@ -134,8 +134,8 @@ PART 1
===================================== ==================================
Obiettivo Come si vede
===================================== ==================================
-Setup di Django Usare il *Django test server* e
- navighiamo al manuale a la pagina
+Setup di Django Usare il *Django development server*
+ e navighiamo al manuale a la pagina
"Hello World"
------------------------------------- ----------------------------------
Setup del' sito admin Iniziamo il primo *functional test*,
View
3 tdd-feedback.txt
@@ -3,8 +3,6 @@ Feedback:
General:
! Your site's 404 shows that debug=True... https://docs.djangoproject.com/en/dev/ref/settings/#debug
- + references to "test server" should be "development server" like the official Django docs, to reduce ambiguity, particularly since "test" is a new term to the typical viewer
- - references to 'tests.py' are not descriptive enough- there are at least two files of that name.
+ consider moving the filename accompanying each script box to the top left corner. i was in Part 3 before i even noticed it, and had been guessing which of the `tests.py` to use. In the case of smaller resolutions, it might not be visible until until all the code has been read.
- especially since there is refactoring involved, it might be helpful to have a version of the code that corresponds to the expected results after each lesson (perhaps as a tag, or branch). This could also help a user jump in at any lesson.
- i found the fts to be spotty (i suspect a selenium issue); they would often fail early in an unreproducable manner. After repeatedly hitting the fts, i would be able to power through. Any word on that? Examples:
@@ -54,7 +52,6 @@ General:
Part 1
- + some images in /tutorial/1/ are not rendering, but showing something like `.. image:: /static/images/django_admin_login.png`
- don't like the "yes, we really meant it" explanation of INSTALLED_APPS. Prefer something like the "enabled" language in https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps
- `Ran 323 tests in 2.402s` before "Hooray! The joy of unbroken..." should say `Ran 1 test in ...s`
- "It's OK to ignore these for now - we'll deal with templates for 500 errors in a later tutorial." ... i didn't find that later tutorial, but nominate Part 3
View
28 tutorial01.rst
@@ -36,8 +36,8 @@ So here are our objectives for this first tutorial:
========================================= ==================================
Objective How will we know we've succeeded?
========================================= ==================================
-Set up Django Run the *Django test server* and
- manually browse the default
+Set up Django Run the *Django development server*
+ and manually browse the default
"Hello World" page
----------------------------------------- ----------------------------------
Set up the Django admin site Write our first *functional test*,
@@ -109,10 +109,10 @@ This tutorial is written for 1.4 -- bleeding edge FTW! -- but if you're stuck
with an earlier version, you should find most things work with a little
tweaking, as long as you get yourself a hold of a LiveServerTestCase backport)*
-Checking we've succeeded: running the test server
--------------------------------------------------
+Checking we've succeeded: running the development server
+--------------------------------------------------------
-Django comes with a built-in test server which you can fire up during
+Django comes with a built-in development server which you can fire up during
development to take a peek at how things are looking. You can start it up by
typing::
@@ -124,7 +124,7 @@ should see something a bit like this:
.. image:: /static/images/django_it_worked_default_page.png
-There's more information about the test server here:
+There's more information about the development server here:
https://docs.djangoproject.com/en/1.4/intro/tutorial01/#the-development-server
Now, manual tests like the one we've just done are all very well, but in TDD
@@ -133,7 +133,7 @@ automated test.
I did want to introduce ``runserver`` at the outset though - that way, at any
point during this tutorial, if you want to check what the site actually looks
-like, you can always fire up the test server and have a look around
+like, you can always fire up the development server and have a look around
Starting our first functional test: The Django admin site
@@ -213,9 +213,9 @@ Your directory tree will now look like this::
`-- wsgi.py
-Now, let's open up the ``tests.py`` file inside the ``fts`` folder, and write
-our first Functional test. You can delete the example test case that Django
-have put in there, and replace it with this:
+Now, let's open up the ``fts/tests.py`` file (inside the ``fts`` folder), and
+write our first Functional test. You can delete the example test case that
+Django have put in there, and replace it with this:
.. sourcecode:: python
:filename: mysite/fts/tests.py
@@ -556,7 +556,7 @@ take for our site.::
python manage.py runserver
If you take another look at ``http://localhost/``, you will probably see an
-error message like this::
+error message like this:
.. image:: /static/images/page_not_found_debug_error.png
@@ -586,7 +586,7 @@ needs. For this we use a command named ``syncdb``.
In this case, syncdb will notice it's the first run, and proposes that you
create a superuser. Let's go ahead and do that (you may have to hit Ctrl-C to
-quit the test server first)::
+quit the development server first)::
python manage.py syncdb
@@ -601,12 +601,12 @@ password for the superuser.:::
Superuser created successfully.
-Let's see if that worked - try firing up the test server again::
+Let's see if that worked - try firing up the development server again::
python manage.py runserver
And if you go back to ``http://localhost/admin/``, you should see the Django
-login screen::
+login screen:
.. image:: /static/images/django_admin_login.png
View
4 tutorial02.rst
@@ -24,8 +24,8 @@ Here's an outline of what we're going to do:
Inspecting the admin site to decide what to test next
-----------------------------------------------------
-Let's fire up the test server, and do a bit of browsing around the admin site -
-that way we can figure out what we want the "Polls" bit to look like.::
+Let's fire up the development server, and do a bit of browsing around the admin
+site - that way we can figure out what we want the "Polls" bit to look like.::
python manage.py runserver
View
6 tutorial03.rst
@@ -260,7 +260,7 @@ that will deal with producing a response for them. These functions are called
(*This is essentially an MVC pattern, there's some discussion of it here:*
https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names)
-Let's add a new test to ``tests.py``. I'm going to use the Django Test Client,
+Let's add a new test to ``polls/tests.py``. I'm going to use the Django Test Client,
which has some helpful features for testing views. More info here:
https://docs.djangoproject.com/en/1.4/topics/testing/
@@ -443,7 +443,7 @@ template system - that will provide a much more natural way to write web pages.
The Django TestCase lets us check whether a response was rendered using a
template, by using a special method response called ``assertTemplateUsed``, so
-let's use that. In ``tests.py``, add an extra check to our view test:
+let's use that. In ``polls/tests.py``, add an extra check to our view test:
.. sourcecode:: python
:filename: mysite/polls/tests.py
@@ -763,7 +763,7 @@ Let's use the ``reverse`` function in our tests. Its first argument is the
name of the view that handles the url, and we can also specify some arguments.
We'll be making a view for seeing an individual `Poll` object, so we'll
probably find the poll using its ``id``. Here's what that translates to in
-``tests.py``:
+``polls/tests.py``:
.. sourcecode:: python
:filename: mysite/polls/tests.py
View
2 tutorial04.rst
@@ -307,7 +307,7 @@ https://docs.djangoproject.com/en/1.4/intro/tutorial04/
But Django can do even better than that - Django's forms system will generate
radio buttons for us, if we can just give it the right incantations. Let's
-create a new test in ``tests.py``:
+create a new test in ``polls/tests.py``:
.. sourcecode:: python
View
6 tutorial05.rst
@@ -85,11 +85,11 @@ If you run the FTs, you should see something like this::
What's happening is that clicking the submit button has no effect - we just
stay on the voting page. So, we'll need to wire up our view so that it deals
-with form submission. Let's open up ``tests.py``. We need to find the test
+with form submission. Let's open up ``polls/tests.py``. We need to find the test
that deals with our view.
At this point, you might find it's getting a little hard to find your way
-around ``tests.py`` - the file is getting a little cluttered. I think it's
+around ``polls/tests.py`` - the file is getting a little cluttered. I think it's
time to do some *refactoring*, and move things around a bit.
@@ -135,7 +135,7 @@ this:
* add a ``__init__.py`` file inside the ``tests`` folder, to make it into
an importable Python module
- * move the current ``tests.py`` into the ``tests`` folder
+ * move the current ``polls/tests.py`` into the ``polls/tests/`` folder
* finally, ``import`` all of the tests from ``tests.py`` into the
``__init__.py``
View
62 workshop.rst
@@ -26,6 +26,10 @@ checkout the base repo::
+
+
+
+
Introduction
============
@@ -56,6 +60,8 @@ Laptops, tools and working
+
+
The Plan
--------
@@ -68,21 +74,12 @@ The Plan
- first unit tests
- models.py, admin.py
- - PART 2: Customising the admin site
- - extending the FT
- - add a second model: Choice
- - more detailed unit tests
-
- - PART 3: the site home page
+ - PART 2: the site home page
- the Django Test Client
- views.py
- templates
- - PART 4: individual poll voting page
- - more advanced urls
- - forms
-
- - PART 5: form processing
+ - PART 3: (if time)
- POST request
- refactoring
@@ -91,6 +88,12 @@ The Plan
+
+
+
+
+
+
How we will work
----------------
@@ -115,6 +118,14 @@ How we will work
+
+
+
+
+
+
+
+
PART 1:
=======
@@ -132,16 +143,13 @@ Now we follow ``tutorial01.rst``
Some notes:
- - in the bit where I suggest a ``wget``, you can just ``mv`` the
- ``functional_test.py`` from where I've put it in the root of the repo into your
- ``mysite`` directory...
-
- notes for windows users:
- ``https`` checkout for github
- ``move`` not ``mv``.
- ``django-admin.py startproject mysite`` (note extra .py)
- ``python manage.py runserver 8001``
+
Extra practice:
- try to use ``element.click()`` to click submit button instead of pressing
@@ -157,22 +165,17 @@ Extra practice:
-PART 2:
-=======
-Now we follow ``tutorial02.rst``
-Simplifications:
- - start by using "Pub date", rather than "Date Published"
- - similarly, just assert we see a link with "Poll object" on next screen
- - never mind unit test for verbose_name
-PART 3:
+
+
+PART 2:
=======
Checkout next part::
@@ -184,3 +187,16 @@ Now we follow ``tutorial03.rst`` , starting from the section called
**At last! An FT for a normal page** (circa line 175)
+
+
+
+
+
+
+
+
+
+
+
+
+

0 comments on commit 1e963b1

Please sign in to comment.