On Thu, Dec 18, 2008 at 8:49 PM, Jorge Vargas <[email protected]> wrote:
>
> On Thu, Dec 18, 2008 at 4:14 PM, Ben Bangert <[email protected]> wrote:
>> On Dec 18, 2008, at 7:55 AM, Jorge Vargas wrote:
>>
>>> Hi, I'm writing unit tests and I was wondering if there is a way to
>>> ask routes for all possible urls it can handle. if this is not, there
>>> how hard will it be to implement? Ideally I want to mix this with
>>> webtest so I can have a generic test that will tell me if all urls I'm
>>> calling are ok, by ok I mean no 400 or 500 errors, I know this is
>>> going to be harder for the POSTs but for all the GETs it should be a
>>> nice addition to the testsuite.
>>
>> Sort of. You can get all the routes out, and the paths that you setup,
>> that's about it. You'd have to crawl all your controllers, and find all
>> methods that could be gotten to publicly to find every execution path
>> though.... not exactly ideal.
>
> yea I think that is what I'll ultimately do if there isn't a better
> solution. I honestly don't know routes well enough to know if this is
> even possible. One alternative solution will be to find all calls to
> url_for and try to execute them, the other will be to track the
> @expose, that should give you at least a set where to start that could
> be manually edited to add proper fields.
>
> for example /foo/:bar will be "catch" by the analyzer, then you could
> replace that for a set of valid urls that match your test environment,
> like if :bar is a field in the db, then you could replace that with
> /foo/validTestData1, /foo/validTestData2, /foo/IDontExist,
> /foo/validTestData1/, /foo/validTestData2/,, and then pass that list
> to something like what Mike suggested.
There are two issues here. One is whether the routes work; the other
is whether all your actions work. I still think you're best off
making a separate list of intended URLs. You don't have to test every
possible ID, which is obviously impossible, but you can test a few
representative IDs, including some with non-word characters.
As I said, Routes' internal structure is undocumented, and last time I
looked inside it to figure out a resource route issue, it didn't look
very straightforward. That's one of my goals with Routes 2 is to make
a more reflectable structure. But now that most of Routes 2's
features have been backported to Routes 1, and I have plenty of other
work the next couple months, I'm not sure how much it's worth
pursuing.
Whenever I start a new project, the first thing I do is draw out the
URL structure, and show the sequence of URLs a user would visit to
perform typical operations ("Go to dictionary, look up word, read
definition"; "Add object, later delete it".) Then I make the routing
and then the controllers. What you're talking about is a
manifestation of part 1, which can serve both as documentation and as
test data. Perhaps Routes should support this, but it currently
doesn't. Nevertheless I think it would be helpful to put this as
close to the route definitions as possible.
Another idea would be to just put the URLs in a text file, one per
line, and then a test tool could just read the file and verify them
all. If it ignores blank lines and lines starting with "#", the file
could also double as documentation.
--
Mike Orr <[email protected]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
