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

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*,

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

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
 

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
 

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

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

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``

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)
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+