On Thu, Dec 18, 2008 at 11:12 PM, Mike Orr <[email protected]> wrote:
>
> 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.
>
This is good to heard, I was wondering what happen there. Thanks for the Update.
> 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.
>
Yes in this particular project we started that way, but some changes
by some particular developer forced us to change our original
structure therefore now we are stuck with a
franken-rest-url-structure, so I was thinking that in order to fix our
tests I could ask routes to do "part 1" from me based on the code so
we could back-track from there, to get unittests back in place where
they should be.
> 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.
Yes this is what I was referring to when I said "scan" I was thinking
visually not code wise.
Thanks for your feedback.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
