Python Web Framework Series – Pylons: Part 5 Testing Models

2 July, 2009. It was a Thursday.

UPDATE: was an error caught by Govind (who is turning out to be my unofficial proofreader). I’ve made a correction in the thread mapping for “dateadded” property in the previous article. If this you are caught up with and error indicating there is no dateadded property on thread make sure to edit your model__init__.py file to match the previous article and rebuild your db so that everything is happy. Please bear with me as I hone my tutorial writing skill set.

When we last left of with our Pylons forum we had a had just successfully created a post, and then could immediately retrieve that same post. However, we kind of skimped on the testing story so lets fill in the gaps and do some refactoring as a bonus.

Functional Testing Models

Open your functional controller test located at pylonsforumtestsfunctionaltest_home.py and add the following import line

    from pylonsforum.model import Thread, Post, meta
  

and the following methods

defsetUp(self):
     meta.Session.remove()
     meta.metadata.create_all(meta.engine)
self._createpost(5)</p> 
    
      def _createpost(self,times):
         i = 
         while i < times:
             i = i +1
             thread = Thread()
             thread.subject = “subject “ + str(i)
             post = Post()
             post.author = “posting away”
             post.content= “”
             post.isparent = True
             thread.posts.append(post)
             meta.Session.add(thread)
         meta.Session.commit() </div> </div> 
      
        and change the test_recent_posts method to
      
             def test_five_most_recent_threads_show_in_homepage(self):
         response = self.app.post(url(controller=“home”, action=“index”))
         assert “subject 1” in response
         assert “subject 2” in response
         assert “subject 3” in response
         assert “subject 4” in response
         assert “subject 5” in response
        
        In summary here we’re adding a _createpost factory method that generates some basic test threads and parent posts. running nosetests –-with-pylons=test.ini should result in failed tests.
      
        Changing The View and Controller
      
        Now adjust your index.mako view to the following:
      
          <%def name=“title()”>Pylons Forum</%def>
 <%def name=“head_tags()”></%def>
 <div id=“recentposts”>
 </b></span>
</b></span>
 %for t in c.threads:
      </b></span>subject</th></b></span>author</th></b></span>date submitted</th></tr></thead>
 
</b></span>${t.subject}</td></b></span>${t.parentpost.author}</td></b></span>${t.dateadded}</td></tr><!– changed posts properties to thread properties and added parentpost –>
%endfor
</tbody>
</table>
</div>
        </div>
      </div>
      
        So once you’ve changed the to using a “threads” object, added parentpost (where did that come from? I’ll get to that in minute) and changed our properties around we need to change the our home.py controller index action for our cosmetic changes and to work with our new tests:
      
           def index(self):
         c.username = “rsvihla”
    # removing this line    c.posts = [Post(“jkruse”, “New Kindle”, “06/24/2009”)]
         thread_query = meta.Session.query(model.Thread)
         c.threads = thread_query.order_by(model.Thread.dateadded.desc()).limit(5).all()
         return render(‘index.mako’)
        
        So our index action now is querying for the 5 most recent threads and storing in our new c.threads context variable. Lets strip the query down into pieces.
      
          thread_query = meta.Session.query(model.Thread)
        
        we’re working with SQLAlchemy Session object. We call a Thread Model and then store a Thread query object inside the thread_query variable.  Now through the thread_query variable we can get  access to the Thread objects stored in the database.
      
          c.threads = thread_query.order_by(model.Thread.dateadded.desc()).limit(5).all()
        
        Here we call “order_by” on our query object and then pass in the Thread model specifying a descending order of the dateadded property. Next we limit it to 5 rows and then call “all()” which returns our results in a nice python “list” object.
      
        Custom Properties on the Model
      
        Ok so back a few paragraphs ago in the index.mako view I stuck in a “parentpost” property on the thread, and I’m quite certain you’re wondering how I did that. So I’ve created the following class teststest_model.py
      
frompylonsforum.modelimport Thread, Post, meta
frompylonsforum.testsimport*</p> 
          
            class TestThreadParent(TestController):
          
                def _makethread(self, hasparent):
         thread = Thread()
         thread.subject = “test”
         parentpost = Post()
         parentpost.content = “”
         parentpost.author = “first post”
         parentpost.isparent = hasparent
         childpost = Post()
         childpost.content = “”
         childpost.author = “”
         childpost.isparent = False
         thread.posts.append(childpost)
         thread.posts.append(parentpost)
         return thread
          
                def test_should_find_parent_post(self):
         thread = self._makethread(True)
         assert thread.parentpost.author == “first post”
          
                def test_should_not_find_parent_when_none_set(self):
         thread = self._makethread(False)
         assert thread.parentpost is None </div> </div> 
            
              Our test has a _makethread factory method (another one of those maybe time for a factory class soon!) which can make a parent post or not depending on its parameter, then two tests documenting its behavior in each situation.
            
              So I’ve gone back to our models__init__.py class and changed the Thread class to look like this:
            
                class Thread(object):
     @property
     def parentpost(self):
         for p in self.posts:
             if p.isparent == True:
                 return p
              
              Not the best method however its VERY interesting for static language veterans. We are searching an instance variable that we have not even defined!  Remember only our SQLAlchemy mapper even makes mention of a “posts” variable through our relationship mapping, yet our “parentpost” property is searching through self.posts.  Once it finds a parent post it returns true, this is not perfect and again not the ideal way to enforce a database constraint but for a demo it works fine.
            
              Calling nosetests –-with-pylons=test.ini should now give you all passing tests. Running paster serve –-reload development.ini and opening http://localhost:5000 , adding a couple of threads and you should have something that looks like this:
            
              Summary
            
              We’ve completed a home page now that has some dynamic data, added a custom property on our database class, and addressed functional testing with models.

</b></span>subject</th>	</b></span>author</th>	</b></span>date submitted</th></tr></thead>
</b></span>${t.subject}</td>	</b></span>${t.parentpost.author}</td>	</b></span>${t.dateadded}</td></tr> <!– changed posts properties to thread properties and added parentpost –> %endfor </tbody> </table> </div> </div> </div> So once you’ve changed the to using a “threads” object, added parentpost (where did that come from? I’ll get to that in minute) and changed our properties around we need to change the our home.py controller index action for our cosmetic changes and to work with our new tests: def index(self): c.username = “rsvihla” # removing this line c.posts = [Post(“jkruse”, “New Kindle”, “06/24/2009”)] thread_query = meta.Session.query(model.Thread) c.threads = thread_query.order_by(model.Thread.dateadded.desc()).limit(5).all() return render(‘index.mako’) So our index action now is querying for the 5 most recent threads and storing in our new c.threads context variable. Lets strip the query down into pieces. thread_query = meta.Session.query(model.Thread) we’re working with SQLAlchemy Session object. We call a Thread Model and then store a Thread query object inside the thread_query variable. Now through the thread_query variable we can get access to the Thread objects stored in the database. c.threads = thread_query.order_by(model.Thread.dateadded.desc()).limit(5).all() Here we call “order_by” on our query object and then pass in the Thread model specifying a descending order of the dateadded property. Next we limit it to 5 rows and then call “all()” which returns our results in a nice python “list” object. Custom Properties on the Model Ok so back a few paragraphs ago in the index.mako view I stuck in a “parentpost” property on the thread, and I’m quite certain you’re wondering how I did that. So I’ve created the following class teststest_model.py from pylonsforum.model import Thread, Post, meta from pylonsforum.tests import </p> class* TestThreadParent(TestController): def _makethread(self, hasparent): thread = Thread() thread.subject = “test” parentpost = Post() parentpost.content = “” parentpost.author = “first post” parentpost.isparent = hasparent childpost = Post() childpost.content = “” childpost.author = “” childpost.isparent = False thread.posts.append(childpost) thread.posts.append(parentpost) return thread def test_should_find_parent_post(self): thread = self._makethread(True) assert thread.parentpost.author == “first post” def test_should_not_find_parent_when_none_set(self): thread = self._makethread(False) assert thread.parentpost is None </div> </div> Our test has a _makethread factory method (another one of those maybe time for a factory class soon!) which can make a parent post or not depending on its parameter, then two tests documenting its behavior in each situation. So I’ve gone back to our models__init__.py class and changed the Thread class to look like this: class Thread(object): @property def parentpost(self): for p in self.posts: if p.isparent == True: return p Not the best method however its VERY interesting for static language veterans. We are searching an instance variable that we have not even defined! Remember only our SQLAlchemy mapper even makes mention of a “posts” variable through our relationship mapping, yet our “parentpost” property is searching through self.posts. Once it finds a parent post it returns true, this is not perfect and again not the ideal way to enforce a database constraint but for a demo it works fine. Calling nosetests –-with-pylons=test.ini should now give you all passing tests. Running paster serve –-reload development.ini and opening http://localhost:5000 , adding a couple of threads and you should have something that looks like this: Summary We’ve completed a home page now that has some dynamic data, added a custom property on our database class, and addressed functional testing with models.

← Python Web Framework Series – Pylons: Part 4 Introduction For Database Support With SQL Alchemy.

Python Web Framework Series – Pylons: Part 6 Basic Authorization With AuthKit →