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.
Open your functional controller test located at pylonsforumtestsfunctionaltest_home.py and add the following import line
and the following methods
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
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.
Now adjust your index.mako view to the following:
</b></span>subject</th> | </b></span>author</th> | </b></span>date submitted</th></tr></thead> </b></span> %for t in c.threads: </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 ModelOk 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):
def test_should_find_parent_post(self):
def test_should_not_find_parent_when_none_set(self): 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: SummaryWe’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. |
---|