I would like to unit test a view. How can I invoke a view and get the results back as a string? Thanks David
On 5/16/05, David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> wrote:> I would like to unit test a view. How can I invoke a view and get the results > back as a string?This is what functional tests are for. -- Urban Artography http://artography.ath.cx
On Monday 16 May 2005 10:55 pm, Rob Park wrote:> On 5/16/05, David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> wrote: > > I would like to unit test a view. How can I invoke a view and get the > > results back as a string? > > This is what functional tests are for.In your view of devlopment, maybe, but not mine. So my question still stands.
On Tuesday 17 May 2005 06:44 am, David Corbin wrote:> On Monday 16 May 2005 10:55 pm, Rob Park wrote: > > On 5/16/05, David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> wrote: > > > I would like to unit test a view. How can I invoke a view and get the > > > results back as a string? > > > > This is what functional tests are for. > > In your view of devlopment, maybe, but not mine. So my question stillLet me appologize now for my terse reply. I knew I should have said I didn''t want to hear about functional tests in my original posting, so it I got a bit snappy. I''ve only been playing with Rails for a little while, and this is one of my biggest downsides so far. The tests are extremely unfocused. Two thirds of the system (controllers, views) are not unit tested, and even the other third (models) are not unit tested (by my definition), because the database is involved, though I can get over this one more easily than the FT. I want my unit tests to be very focused on the code I write, and I want them to run quicly. In my day-job, our core project (Java) has over 3400 unit tests, and they run in < 30 seconds. The speed with they run is very important, and introducing other layers and systems does slows them down significantly. David
Using the standard definition of what a unit test is (compared to say a functional, integration, smoke or system tests) you are limited in what you can functionally test. Even your models cannot be seperated from the DB cleanly so in effect you''re testing the DB. The fact that Rails plays hard and fast with the definition of ''unit'' and ''functional'' tests is going ot lead to confusion. But as David said, the stubs in the functional-test folders should let you test a view - you just need to invoke a controller to render a view, then carry out assertions on the page returned if you want. Thinking about this, has anyone done a Ruby version of Fit? sam On 5/17/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote:> On Tuesday 17 May 2005 06:44 am, David Corbin wrote: > > On Monday 16 May 2005 10:55 pm, Rob Park wrote: > > > On 5/16/05, David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> wrote: > > > > I would like to unit test a view. How can I invoke a view and get the > > > > results back as a string? > > > > > > This is what functional tests are for. > > > > In your view of devlopment, maybe, but not mine. So my question still > > Let me appologize now for my terse reply. I knew I should have said I didn''t > want to hear about functional tests in my original posting, so it I got a bit > snappy. > > I''ve only been playing with Rails for a little while, and this is one of my > biggest downsides so far. The tests are extremely unfocused. Two thirds of > the system (controllers, views) are not unit tested, and even the other third > (models) are not unit tested (by my definition), because the database is > involved, though I can get over this one more easily than the FT. > > I want my unit tests to be very focused on the code I write, and I want them > to run quicly. In my day-job, our core project (Java) has over 3400 unit > tests, and they run in < 30 seconds. The speed with they run is very > important, and introducing other layers and systems does slows them down > significantly. > > David-- sam http://www.magpiebrain.com/
>> I would like to unit test a view. How can I invoke a view and get >> the results >> back as a string? > > This is what functional tests are for.either be helpful or don''t respond :) _a
I hijacked this thread because my response is broad:> Using the standard definition of what a unit test is (compared to say > a functional, integration, smoke or system tests) you are limited in > what you can functionally test. Even your models cannot be seperated > from the DB cleanly so in effect you''re testing the DB.Re: the model testing bound to DB problem, I think that''s perfectly fine - after all, my RoR app w/o a database connection is sort of like a car with no gas tank :) I wanted to comment on the tests that RoR has, and put in some ideas that I developed for binarycloud but that didn''t get into the framework: When you are testing a web app, you tend to want to test the following: -services (is the service even running and responding to requests at the URLs I expect? if it is, is the webserver _only_ functional but my app disabled because the (database is down, email can''t be sent, whatever) -functions (does this method do what I think I said in the code?) -processes (does the registration process with user confirmation work as I designed it?) -data (can I get any bad data into my system? can my system generate bad data? if I put data in via HTTP POST or SOAP etc, is the data stored in the DB what I expect given my input?) -output (is my xhtml valid on every page? is my CSS valid? is my app printing an error? has someone defaced my site do it displays something I didn''t intend?) -performance (simple benchmarking and stress testing) For basic service monitoring, I use monit to check a set of URLs: -the root uri just for port response -a "permissions are correct" url which returns TRUE or FALSE -a "DB Connection + Query is valid" url which returns TRUE or FALSE -a couple URIs (usually static) for MD5 checksum Unit tests are great for functions. A real browser simulation package is necessary for process testing: http://pbp.berlios.de/ Data testing can be done with unit tests for a model (I think, in rails?) but should also be done with a combination process testing and basic checks in the DB. Output testing can be done externally (I have a little tidy script which I use that works wonderfully) - but it would be _FAR_ better for output validation to be done within the framework. Obviously it must be in development only and configurable, because it slows every page render - but that kind of output checking embedded in every page can help to debug presentation problems that are only present in protected areas of the site that require a complex context (i.e. user session). It is most important to log all the output checking so that errors can be reported on without the developer noticing on a specific page render. CSS validity is easy. Error checking should be done with a tool like monit searching for a specific string in the output - This may be useless with RoR''s production switch, so it might be more useful to test for the content of the "DB is down" catchall page or sth. (I love monit, can you tell?) Performance testing can be done externally with a tool like AB or similar, internal performance testing that writes results to a history from which a report can be generated is the most useful - has anyone done this for RoR? ---------- I think if you cover those bases (which are ugly and there are a lot of them), you''re in good shape :) That said, a lot of them can be integrated right into the framework so they become effortless: look at the list of your output errors at some URI and fix them, then re-test :)> carry out assertions on the page returned if you want. Thinking about > this, has anyone done a Ruby version of Fit?That''s very cool. How do you do it? :) _alex -- alex black, founder the turing studio, inc. 510.666.0074 root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
>> carry out assertions on the page returned if you want. Thinking about >> this, has anyone done a Ruby version of Fit? >Yes! http://fitnesse.org/FitServers.RubyFit Another thing: instead of sumulating a browser, you can use a real one in your tests. Check out Selenium (works via JavaScript) and Watir (drives Internet Explorer via its COM interface). Watir is simpler and easier to use than Selenium, but it''s limited to MSIE/Windows. Instiki has some beginnings of a Watir test suite here: http://dev.instiki.org/file/instiki/trunk/test/watir/e2e.rb -- Best regards, Alexey Verkhovsky Ruby Forum: http://ruby-forum.org (moderator) RForum: http://rforum.andreas-s.net (co-author) Instiki: http://instiki.org (maintainer)
> The fact that Rails plays hard and fast with the definition of ''unit'' > and ''functional'' tests is going ot lead to confusion. But as David > said, the stubs in the functional-test folders should let you test a > view - you just need to invoke a controller to render a view, then > carry out assertions on the page returned if you want.I know that I can do that, But I want to be able to write my focused UTs. So I''m just looking for a pointer to how to invoke the rendering logic without having a full-fledge controller involved. David
On 5/18/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote:> > > The fact that Rails plays hard and fast with the definition of ''unit'' > > and ''functional'' tests is going ot lead to confusion. But as David > > said, the stubs in the functional-test folders should let you test a > > view - you just need to invoke a controller to render a view, then > > carry out assertions on the page returned if you want. > > I know that I can do that, But I want to be able to write my focused UTs. So > I''m just looking for a pointer to how to invoke the rendering logic without > having a full-fledge controller involved.What will the views do if the controller hasn''t prepared the instance variables for them? You may be able to implement something that calls ERB directly (http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/index.html)> David > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
On 5/17/05, Alexey Verkhovsky <alex-vV7tgcE2N9Nhl2p70BpVqQ@public.gmane.org> wrote:> Another thing: instead of sumulating a browser, you can use a real one > in your tests. Check out Selenium (works via JavaScript) and Watir > (drives Internet Explorer via its COM interface). Watir is simpler and > easier to use than Selenium, but it''s limited to MSIE/Windows.Yes - I''ve seen that. Aslak bored me with the demo last year. FIT tools (and selenium really is a FIT tool, albiet not using the standard framework) can be very handy - but I''m waiting for tool support for writing the tests themselves so I can get my BA/QA to write them.Oh - and thanks for the link to RubyFit! -- sam http://www.magpiebrain.com/
On 5/17/05, alex black <enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org> wrote:> I hijacked this thread because my response is broad: > > > Using the standard definition of what a unit test is (compared to say > > a functional, integration, smoke or system tests) you are limited in > > what you can functionally test. Even your models cannot be seperated > > from the DB cleanly so in effect you''re testing the DB. > > Re: the model testing bound to DB problem, I think that''s perfectly > fine - after all, my RoR app w/o a database connection is sort of like > a car with no gas tank :)Not really - that implies that the only thing your models are for is for persisting data. The model is supposed to represent your domain - the underlying real-world concepts that your system is attempting to represent. The fact that they are being persisted is an implementation detail, and the mechanism of persistence should not be tied to the representation of real world concepts. ActiveRecord does tie these two things together, so we have to treat them as the same thing unless we want to replace the use of ActiveRecord with our own persitence layer. Luckily Rails is lightweight enough that the impact if implicitly testing the DB all the time normally isn''t too much of a pain. However I''ve frequently wanted to test model behaviour, which as a side effect hits the DB (saves, deletes etc) - I cannot isolate the object behaviour from the DB behaviour, despite the fact that what I really want to be testing is that at most what I want to do is check that by calling a particular method that it interacts with the DB in the way I expected. With a seperate repository layer, I can easily mock out this. As I''ve said beforethis is not some defect in Rails, it''s simply not how ActiveRecord wants to work. From expereice however, the more complex the system, the more complex the DB interactions, and the more likely a seperate repository layer would be necessary. Hopefully by the time I''m doing that they''ll be some alternatives out there to me writing all the SQL myself :-).> Unit tests are great for functions.And with mocking for testing object behaviour - which is not exactly the same thing (for a comparison of state vs behavior testing see http://www.martinfowler.com/articles/mocksArentStubs.html). -- sam http://www.magpiebrain.com/
On Wednesday 18 May 2005 01:17 am, Michael Koziarski wrote:> On 5/18/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote: > > > The fact that Rails plays hard and fast with the definition of ''unit'' > > > and ''functional'' tests is going ot lead to confusion. But as David > > > said, the stubs in the functional-test folders should let you test a > > > view - you just need to invoke a controller to render a view, then > > > carry out assertions on the page returned if you want. > > > > I know that I can do that, But I want to be able to write my focused > > UTs. So I''m just looking for a pointer to how to invoke the rendering > > logic without having a full-fledge controller involved. > > What will the views do if the controller hasn''t prepared the instance > variables for them? > > You may be able to implement something that calls ERB directly > (http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/index.html) >I imagine I''ll get a failure of some type. Testing the interaction between controller and view is a valid use of functional tests, IMO. But first I want unit tests that are focused on the different classes (and to me, each view template is a class). David
On 5/18/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote:> I imagine I''ll get a failure of some type. Testing the interaction between > controller and view is a valid use of functional tests, IMO. But first I > want unit tests that are focused on the different classes (and to me, each > view template is a class).I imagine you''ll probably disagree with me, but... IMHO you shouldn''t have any logic in your view templates that _needs_ to be tested. The only thing they should be doing is echoing out the values of template variable and an occasional, simple loop. All the logic should be contained in controllers (which can be easily achieved by using components). Basically, if you find yourself coding a teplate that has more than one possible path of execution ("if/else" and other flow-control constructs are your flag here), you should refactor your controller to move that logic there. Once this logic has been moved to the controllers, the functional tests will take care of all the testing you need, because you can test both full actions and component actions seperately and perform assertions on the "assigns" collection to ensure that the proper data is passed to your templates. The template itself isn''t a "class" that needs to be unit tested---it''s simply "data" that gets used by the controller. Trying to right a lot of tests against the template by itself (assuming you manage to rafactor your logic into the controller) would be a lot of work for _very_little_ gain (epecially when you consider that any eruby errors in your template will get raised by the functional tests when they are run.) -- Regards, John Wilger ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
On 5/18/05, Sam Newman <sam.newman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> represent. The fact that they are being persisted is an implementation > detail, and the mechanism of persistence should not be tied to the > representation of real world concepts. ActiveRecord does tie these two > things together, so we have to treat them as the same thing unless we > want to replace the use of ActiveRecord with our own persitence layer. > > I cannot isolate the object > behaviour from the DB behaviour, despite the fact that what I really > want to be testing is that at most what I want to do is check that by > calling a particular method that it interacts with the DB in the way I > expected.Technically, shouldn''t it be possible to write a "mock" database adapter that could be used during testing to facilitate this? I haven''t played with it yet, but there is a gem called ''test-unit-mock''. You could probably use this to mock out the database connection and then use that connection inside your unit tests. -- Regards, John Wilger ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
Sam Newman wrote:>Yes - I''ve seen that. Aslak bored me with the demo last year. FIT >tools (and selenium really is a FIT tool, albiet not using the >standard framework) can be very handy - but I''m waiting for tool >support for writing the tests themselves so I can get my BA/QA to >write them.Oh - and thanks for the link to RubyFit! > ><soapbox on> If you mean capture/playback support, then be advised that it''s a common trap. No amount of tool support enables testers to write decent automated tests. Programming skills do. Either you get somebody with programming skills to do it (in which case, there is enough tool support alrteady there, anything else would merely be nice to have, but not necessary, not even very helpful), or you end up with an unmaintainable steaming mound of crud, that will mostly give you false negatives and false positives. It doesn''t take an awful lot of programming skills to write test automation, most testers can (and should!) get it. A good tester who cannot learn to code is a rare beast. <soapbox off> -- Best regards, Alexey Verkhovsky Ruby Forum: http://ruby-forum.org (moderator) RForum: http://rforum.andreas-s.net (co-author) Instiki: http://instiki.org (maintainer)
> Technically, shouldn''t it be possible to write a "mock" database > adapter that could be used during testing to facilitate this? I > haven''t played with it yet, but there is a gem called > ''test-unit-mock''. You could probably use this to mock out the database > connection and then use that connection inside your unit tests.That''s interesting. I worked on the SixthDay web framework in python for a bit. It included the Clerk module for DB access (very similar to AR), and a MockClerk that would simulate updating rows using an array of hashes as a test database. Classes like SqliteClerk and MySqlClerk had the exact same interface. It worked well I suppose... -- rick http://techno-weenie.net
On Wednesday 18 May 2005 08:45 am, John Wilger wrote:> On 5/18/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote: > > I imagine I''ll get a failure of some type. Testing the interaction > > between controller and view is a valid use of functional tests, IMO. But > > first I want unit tests that are focused on the different classes (and to > > me, each view template is a class). > > I imagine you''ll probably disagree with me, but...Well, not in principle. I do want my views to be VERY thin, and very stupid :)> IMHO you shouldn''t > have any logic in your view templates that _needs_ to be tested. > only thing they should be doing is echoing out the values of template > variable and an occasional, simple loop. All the logic should be > contained in controllers (which can be easily achieved by using > components). Basically, if you find yourself coding a teplate that has > more than one possible path of execution ("if/else" and other > flow-control constructs are your flag here), you should refactor your > controller to move that logic there.Well, loops often involve conditionals, though certainly it''s more rare in Ruby than in Java. I''m all for refactoring the logic out of the view. All the logic I write in my web-views currently is presentation logic. It''s only about how the presented web page should look. In my day-job (GUI, not web), we''ve managed to create a very thin UI model and controllers do contain all the logic, and so I do understand the concept. I''ve not really tried to do that 100% with my web-work (yet), but my instinct is that this will result in lots and lots and lots of html fragments that get assembled in a very piecemeal fashion, OR I end up with a HTML embedded in my ruby code, which I don''t much care for. But, I''ll give it a try, and I expect you''ll see a posting or two here with some specific example/questions... (I''m not a big fan of the ERB/JSB style of presenting a web page anyway, but it''s what we have here at the moment). David
> > IMHO you shouldn''t > > have any logic in your view templates that _needs_ to be tested. > > only thing they should be doing is echoing out the values of template > > variable and an occasional, simple loop. All the logic should be > > contained in controllers (which can be easily achieved by using > > components). Basically, if you find yourself coding a teplate that has > > more than one possible path of execution ("if/else" and other > > flow-control constructs are your flag here), you should refactor your > > controller to move that logic there. > > Well, loops often involve conditionals, though certainly it''s more rare in > Ruby than in Java.One more thing, which I didn''t mention. I''m used to test-driving all my code, and that includes views. David
On 5/19/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote:> One more thing, which I didn''t mention. I''m used to test-driving all my code, > and that includes views.Views independent of their controllers? I''m still confused about what exactly you''ll be testing. take this def index @user = User.find(@params[:id]) end index.rhtml <p>Hello <%= @user.name %></p> Now you can unit test the controller, make sure it sets @user to a user. You can test the result of calling the action contains "<p> Hello Michael Koziarski</p>". How would you go about testing that view on its own? assert_raises NoMethodError? (http://manuals.rubyonrails.com/read/chapter/28) .> David > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
On 5/17/05, Sam Newman <sam.newman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> ... has anyone done a Ruby version of Fit?Take a look at MiniRubyWiki (written by Phlip): http://rubyforge.org/projects/minirubywiki/ http://www.rubygarden.org/ruby?MiniRubyWiki>From the initial release announcement:"MRW competes with http://fitnesse.org as a wiki that transcludes test resources. Like FIT, MRW edits and executes tests, and collects their graphical output. Unlike FIT, MRW stores test resources in XML, and edits them directly in the web page without editing the Wiki source. These advanced features will allow shops without Java to rapidly begin XP-style acceptance tests without the overhead of FIT." Ken
If however your DB access was handled by an (eric evan''s stylee) repository layer, wtih stuff like: repository.save(model) repository.delete(model) repositorty.find etc Then you can use RMock/RubyMock/TestMock/whatever to mock the repository out... sam On 5/19/05, Rick Olson <technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Technically, shouldn''t it be possible to write a "mock" database > > adapter that could be used during testing to facilitate this? I > > haven''t played with it yet, but there is a gem called > > ''test-unit-mock''. You could probably use this to mock out the database > > connection and then use that connection inside your unit tests. > > That''s interesting. I worked on the SixthDay web framework in python > for a bit. It included the Clerk module for DB access (very similar > to AR), and a MockClerk that would simulate updating rows using an > array of hashes as a test database. Classes like SqliteClerk and > MySqlClerk had the exact same interface. It worked well I suppose... > > -- > rick > http://techno-weenie.net > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- sam http://www.magpiebrain.com/
On 5/19/05, Sam Newman <sam.newman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> If however your DB access was handled by an (eric evan''s stylee) > repository layer, wtih stuff like: > > repository.save(model) > repository.delete(model) > repositorty.find > > etc > > Then you can use RMock/RubyMock/TestMock/whatever to mock the repository out... > > samActiveRecord uses connection adapters, right? Why not write a Mock Connection adapter? The tough part would be getting it to understand SQL though... This is how that Sixthday system I mentioned worked. Clerk objects took basic StrongBox objects (the models) and persisted them to the DB. I implemented something called QueryBuilders in Sixthday. It was basically an object with overridden operator methods, but you could build SQL queries in python code. Instead of writing: "name = ''bob'' or name = ''fred''" you''d write: (q.name == ''bob'') or (q.name == ''fred'') The side effect was I could take those objects in the MockClerk object and perform complex queries on the rows of hashes that it uses internally. Okay okay, I yanked the idea from SQLObject. (http://sqlobject.org/docs/SQLBuilder.html) -- rick http://techno-weenie.net
On Wednesday 18 May 2005 09:00 pm, Michael Koziarski wrote:> On 5/19/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote: > > One more thing, which I didn''t mention. I''m used to test-driving all my > > code, and that includes views. > > Views independent of their controllers?Absolutely.> I''m still confused about what > Now you can unit test the controller, make sure it sets @user to a > user. You can test the result of calling the action contains "<p> > Hello Michael Koziarski</p>".I know you can write a functional test to do that. But I also know you can unit test this. And in my view, anything that can be unit tested should be (short of maybe a simple attr_reader/attr_writers. In Ruby, I''m not even sure I should skip that). Functional testing has its place, but I will always favor UTs over FTs when I can.> > How would you go about testing that view on its own? assert_raises > NoMethodError? >For this case, I''d probably do change it a bit to be like this: <p id=''hello''>Hello <%= @user.name %></p> and then I''d use REXML to find the tag with id=''hello'', and make sure it ends in the value the my @user object returned for "name". Sorry I don''t have an explicit example with real code, but I''ve not done this in Ruby. (I''ve done it in Java David
Consdier this fragment of an .rhtml file. (If it matters, this inside a
loop):
<% if game.started %>
<td><%= link_to ''Show'', :action =>
''show'', :id => game %></td>
<td><%= link_to ''Edit'', :action =>
''edit'', :id => game %></td>
<% else %>
<td><%= link_to ''Start'', :action =>
''start'', :id => game %></td>
<% end %>
I can see the following approaches to eliminating the if/else:
1) replace the entire block with a helper method.
"showGameActions(game)"
Downsides:
a) [-]I hate using "functions" in OO programs.
b) [-]helper method must(?) contain HTML code (ugh!). It might be doable
with the builder code, but I don''t know as it won''t be valid
XML being
generated).
c) [-]Seperates knowledge that it''s in a table in to very
seperate
areas (poor encapsulation).
d) [+] simple
2) change the controller so it''s not actually providing a list of
Games, but
of "GameListAdapters", which has a method on it
"showActions". This class
would be a presentation-only class.
a) [+] oo
b) [-] a fair amount of "dumb, repetative" code to write for
the
c) [-] Same issues as 1b&c.
3) instantiate a GameListAdapter in the view
a) [-] constructing objects in the view seems wrong
b) [-] same as 1b&c
4) Create a component for this, with two views, and an action just to route
between the two views.
a) [--] A whole lot of effort, it seems for a ''one use''
component.
Anyway, that''s how I see it. Have missed an options? Are any of my
evaluations wrong?
David
David Corbin wrote:>Consdier this fragment of an .rhtml file. (If it matters, this inside a >loop): > > <% if game.started %> > <td><%= link_to ''Show'', :action => ''show'', :id => game %></td> > <td><%= link_to ''Edit'', :action => ''edit'', :id => game %></td> > <% else %> > <td><%= link_to ''Start'', :action => ''start'', :id => game %></td> > <% end %> > >I can see the following approaches to eliminating the if/else: > > >My first thought is - why bother? If this is only being used one place, why introduce extra complexity? Otherwise, why not use a partial? Jack Christensen
On Thursday 19 May 2005 07:39 pm, Jack Christensen wrote:> David Corbin wrote: > >Consdier this fragment of an .rhtml file. (If it matters, this inside a > >loop): > > > > <% if game.started %> > > <td><%= link_to ''Show'', :action => ''show'', :id => game %></td> > > <td><%= link_to ''Edit'', :action => ''edit'', :id => game %></td> > > <% else %> > > <td><%= link_to ''Start'', :action => ''start'', :id => game %></td> > > <% end %> > > > >I can see the following approaches to eliminating the if/else: > > My first thought is - why bother? If this is only being used one place, > why introduce extra complexity? Otherwise, why not use a partial?Well, in part, at this point, it''s an exercise. If the choices I outlined above are the only ones, I''ll likely not do this. But then that leads me back to the view needs to be easily testable as a unit. David
On 5/20/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote:> On Wednesday 18 May 2005 09:00 pm, Michael Koziarski wrote: > > On 5/19/05, David Corbin <dcorbin-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> wrote: > > > One more thing, which I didn''t mention. I''m used to test-driving all my > > > code, and that includes views. > > > > Views independent of their controllers? > > Absolutely. > > > I''m still confused about what > > Now you can unit test the controller, make sure it sets @user to a > > user. You can test the result of calling the action contains "<p> > > Hello Michael Koziarski</p>". > > I know you can write a functional test to do that. But I also know you can > unit test this. And in my view, anything that can be unit tested should be > (short of maybe a simple attr_reader/attr_writers. In Ruby, I''m not even > sure I should skip that). Functional testing has its place, but I will > always favor UTs over FTs when I can. > > > > How would you go about testing that view on its own? assert_raises > > NoMethodError? > > > For this case, I''d probably do change it a bit to be like this: > > <p id=''hello''>Hello <%= @user.name %></p> > > and then I''d use REXML to find the tag with id=''hello'', and make sure it ends > in the value the my @user object returned for "name". Sorry I don''t have an > explicit example with real code, but I''ve not done this in Ruby. (I''ve done > it in JavaMy point is that without a controller, there *is no @user*. Perhaps to put your mind at ease you could create a bunch of testing controllers that *only* populate this stuff and call render for just that fragment?> David >-- Cheers Koz
> Another thing: instead of sumulating a browser, you can use a real one > in your tests. Check out Selenium (works via JavaScript) and Watir > (drives Internet Explorer via its COM interface). Watir is simpler and > easier to use than Selenium, but it''s limited to MSIE/Windows.FYI, the Selenium-Rails integration in the following patch makes working with Selenium in Rails a lot easier. It only works with Webrick (shouldn''t be too hard to get Apache integration working though) but I would almost say it''s easier to use than Watir in it''s current state. http://dev.rubyonrails.com/ticket/1056 http://wiki.rubyonrails.com/rails/show/SeleniumIntegration I haven''t tested the patches for some weeks but I think they should still work. Please give me feedback if there are any problems. Cheers, Jon