I actually wouldn't mind having a nice and easy way to spec partials. They wouldn't work well as acceptance tests of course, it would be cool to be able to set some instance variables, and some partial locals, run the generator, then spec the results using have_selector to get a better sense of progress as you're building up something.
Would be a nice way to work and experient with form helpers, etc, and pieces of your app in the middle of working on something without having to think too deep about end to end testing. This shouldn't be difficult to do as a custom helper. I'll do some research on it, and see if I cant some up with something to package as a merb plugin. On Jan 23, 10:30 pm, Justin Smestad <[email protected]> wrote: > I guess that point about low-level methods is your stance on testing. > I test for the entire stack, but that is another discussion, and a > highly debated one at that. I would point you to here > though:http://evang.eli.st/blog/2009/1/15/how-i-test-controllers-2009-remix > Also this is not a gap in merb testing, this would land more on > webrat and rspec I believe. > > Justin > > On Jan 23, 2009, at 10:50 PM, Phlip wrote: > > > > > Justin Smestad wrote: > > >> I do not mean to answer a question with another question but why test > >> your partial? It should be written in such a reusable way that the > >> code should be near bullet proof. > > > To help write it like that. > > >> If you also follow the partial sans- > >> logic approach than there would be no reason to test a partial other > >> than to create 'artificial code coverage' with a brittle test. > > > For the same reason we test low-level methods, not just the higher > > level ones. > > >> Now to answer your question, the best approach would be to render the > >> partial within the scope that it will be used. Isolated testing only > >> makes sense if your doing particular logic inside the partial which > >> you shouldnt be in the first place. So just check > >> @response.body.should include("the thingy") or better yet > >> @response.body should have_xpath(//@id=...) > > > Confer Rails View Tests that (allegedly) call render on anything - a > > layout, > > partial, inline, file, whatever - and return the result as a string. > > > Next, have_xpath works great in two steps. The first identifies the > > tested > > panel, and the second pinpoints a feature inside it. To whit: > > > xpath :div, :right_menu do > > xpath :a, ?. => 'Contents' > > end > > > Only a link with text 'Contents' inside the right menu panel will > > do. Another > > link with the same text will not foil the test. > > > have_xpath seems to take a block, but I couldn't (briefly) figure > > out how to use > > it. As a research topic, I will not settle for less than rendering a > > partial, > > but of course in a production project I would simply render the > > partial inside > > its page and everything, then I would use a nested XPath test to > > locate the > > partial and then test its innards. > > > If this is a gap in Merb's testing, could someone fix it? > > > -- > > Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
