On 5/28/07, Agustin Villena <[EMAIL PROTECTED]> wrote: > Hi all > > Researching patterns to test-driven-development in frameworks based on the > model view controller, I found this interesting paper > > http://www.purpletech.com/articles/mvc/mvc-and-beyond.html > > In this pattern, there ios a mini-MVC for ecah page on top of the global > MVC. > > Quoting > "Here, the Page Model (the Page Data objects) represents everything that > will show up on the page, in what order, in what language, etc. The page > model represents an overlapping set with the application model. It does not > contain all the information in the application model, merely the subset that > is necessary for the current page to render. However, it is not a subset, > for it also contains other, additional information: for example, which user > is currently logged in, or which page of search results is showing, or an > error message based on an invalid field. > > The Page (View) Renderer objects, in turn, perform a transformation from > the Page Data into HTML. The most logic performed by the Renderer should be > no more sophisticated than simple conditionals or iteration on values and > collections returned by the data model. > > Finally, the Page Servlet (Controller) receives the parameters, creates an > appropriate Page Data (Model), and passes it to a Page Renderer > (View)."Thanks to this model, testing in very much incremental > > Quoting again > " Testability. MMMVC is much easier to test than previous architectures. You > can test that the correct page model gets generated by passing known > parameters to the controller and testing the page model it returns. You can > also test the renderer by passing a known page model and testing its > rendered output. > > Since UI testing is both more difficult and, arguably, less important > (since errors in HTML rendering are more likely to be noticed by humans), > you can reserve the bulk of your test cases for the page model. Indeed, some > Agile programming teams either do not test the UI at all, or write only > rudimentary UI tests; this shortcut is only desirable with a very thin UI > layer on top of a full-fledged data model. > > For instance, if a Menu page must display the Soup du Jour (which changes > every day), the page must not do Date today = new Date(); > int dayOfWeek = today.getDay(); > String soup = data.getSoupForDay(dayOfWeek); > out.print("Soup du Jour: " + soup); > > instead, that functionality must be delegated to the Page Model. Why? > Because otherwise, it becomes impossible to test that Thursday's correct > soup is displayed... unless you're testing on Thursday. out.print("Soup du > Jour: " + data.getSoupDuJour()); > > Note that getSoupDuJour() (with no parameters) is not a member of the > application data model. You must add it to the Page Model." > > > To apply this approach in pylons: > > 1) I must create a page-model oriented layer, that generates the specific > data that the page controller needs. > > > This is already easy in pylons > > > 2) Given a frozen data-set, pass it to the page-view (template) and check if > it is rendered in ehe appropiate way. > > > Well, here is my problem. I don´t know how to make this kind of test. Any > advice? > > > Thanks
I didn't read the link, but I can see what you're saying. Here are a couple tricks I can suggest: * To test your controllers somewhat in isolation, instead of calling render_response, call my_render_response which you write yourself. In my_render_response, in testing mode, you can simply return JSON, and, in real mode, you can return a real page. Then, you can test the data in the JSON--i.e. the page model. * Alternatively, in your site-wide layout, take the entire "c" object, serialize it and shove it in an HTML comment. Then, write a script that can look for the HTML comment and deserialize it. Wham--you suddenly have a way to grab the entire "c" object from the HTML of any generated page. Of course this doesn't work for redirects or when you're generating something other than HTML, but I think that's okay. * I've seen a real test-driven development shop in action using Ruby on Rails. The way they did it was to use pre-arranged data in the database and then test for the presence of data at specific places in the HTML DOM like. For instance, "#name 'Charlie Tuna'" asserts that there must be a name element which contains the known string "Charlie Tuna". This kind of testing is fully automated, of course. Does that help? Best Regards, -jj -- http://jjinux.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
