* Rick Olson ([EMAIL PROTECTED]) [060209 16:15]: > Check out the ActionView tests. Here's the tag helper tests, for example: > > http://dev.rubyonrails.org/browser/trunk/actionpack/test/template/tag_helper_test.rb > > The url_for tests require a controller, so you'll see some of them > creating fake controllers with the bare minimum defined.
Rick, Thanks for the assistance! I guess my question is more about how one has to go about testing these sorts of helpers -- maybe it's more a question of philosophy than feasability. For example, in our case, we had a developer trying to write a functional test for a helper which called link_to(). He ended up in the weeds and I started working with him and quickly came to the realization that we had two options (we were indeed declaring a bare-minimum controller for the test, as #3775 showed): (1) Stub the link_to() method so that the dependency problem ceases to exist. (2) Each time we get an error for a method that can't be found, track down the method in the Rails framework and add a require/include to make it visible. While (2) is a reasonable method to test helpers that are written inside Rails itself (since they are expected to have some knowledge of the layout of the framework), it's a bad Code Smell for tests of helpers in application code. Not only does this technique require ferreting out the location of dependent methods from the Rails class hierarchy, but it forces the tester to do white box testing on the helper method in the first place. The tester has to know that the helper is relying upon certain specific Rails calls to get its job done, and then has to load those specific pieces to get his test written. If the internal helper code changes, the require/include list in the test may well get out of date (more bad smell). If the layout of Rails changes in the future, tests will break because they will fall out of sync with the layout of whichever Rails modules the dependent methods needed in place. Anyway, when Rails is running and a helper is called the call succeeds and the developer never had to go around trying to pick out which Rails modules have to be included to make that helper run. Why should testing that helper suddenly require the developer to become familiar with the layout of the Rails guts? Another way: the helper tests are too damned coupled to the Rails guts. Granted, there's probably more important things to worry about, but if I wanted to write a bunch of library inclusion lines for a snippet of code I'd go back to Java. Seems like there should be a Railsy way to just write the obvious black-box test and not have to fight the framework to get it done. Thanks, Rick -- http://www.rickbradley.com MUPRN: 284 | actually puts random email haiku | them in is an exercise | for the curious. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
