Hi all, I''d like to gauge the interest for a patch before I add to the already large ticket list in Trac. I''ve created a small patch that cleans up functional tests. With this patch applied, functional tests can look just like unit tests. There is no need to open the controller class in order to define a rescue method and there is no need to create the @controller, @request, and @response variables. These are done at runtime, based on the name of the test class. In addition, accessors methods are defined for controller, request, and response. This patch maintains backward compatibility with the current functional test structure, and includes tests for the new functionality. If there is interest in moving this into core, I would be happy to patch the functional test generator to remove the cruft. I''ve made this new behavior available via the TestInjector plugin, which you can view/install from http://www.infused.org/svn/plugins/test_injector, in case you''d like to test out the behavior in your applications. Once you install TestInjector you will automatically get the benefits of the above patch. All of the other functionality of TestInjector has to be explicitly enabled by you. Comments, questions, suggestions? Cheers, Keith Morrison
Hello Keith, 2006/8/17, Keith Morrison <keithm@infused.org>:> Comments, questions, suggestions?My tests are defined like this now: # test/functional/admin_controller_test.rb class UnauthenticatedAccessToAdminSectionTest < Test::Unit::TestCase def setup @controller = AdminController.new .... get :index end def test_redirected_to_login assert ... end def test_warns_in_flash assert ... end def test_logs_unauthorized_access_to_admin assert ... end end class AuthenticatedAccessToAdminSectionTest < Test::Unit::TestCase def setup @controller = AdminController.new @request.session[:user] = ... get :index end def test_allows_access assert ... end end So, with TestInjector, my tests will still need to define @controller, right ? And reopen the right class ? Seems like your plugin would not be very good for me at this time. Unless there was a way it could get at the filename ? Probably not going to be easy. Thanks ! -- François Beausoleil http://blog.teksol.info/ _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On 8/17/06, Keith Morrison <keithm@infused.org> wrote:> Hi all, > > I''d like to gauge the interest for a patch before I add to the already > large ticket list in Trac. > > I''ve created a small patch that cleans up functional tests. With this > patch applied, functional tests can look just like unit tests. There is > no need to open the controller class in order to define a rescue method > and there is no need to create the @controller, @request, and @response > variables. These are done at runtime, based on the name of the test > class. In addition, accessors methods are defined for controller, > request, and response. > > This patch maintains backward compatibility with the current functional > test structure, and includes tests for the new functionality. > > If there is interest in moving this into core, I would be happy to patch > the functional test generator to remove the cruft. > > I''ve made this new behavior available via the TestInjector plugin, which > you can view/install from > http://www.infused.org/svn/plugins/test_injector, in case you''d like to > test out the behavior in your applications. Once you install > TestInjector you will automatically get the benefits of the above > patch. All of the other functionality of TestInjector has to be > explicitly enabled by you. > > Comments, questions, suggestions? > > Cheers, > Keith MorrisonThis sounds very promising, if everything remains 100% compatible I''d love to see it in 1.2/3. One quick question - do you also use this for testing your helpers? I''ve found some of the existing helper_test_cases to be a bit of a pain. - rob
In that case, the plugin won''t help you, but it won''t hinder you either. Francois Beausoleil wrote: Hello Keith, 2006/8/17, Keith Morrison : Comments, questions, suggestions? My tests are defined like this now: # test/functional/admin_controller_test.rb class UnauthenticatedAccessToAdminSectionTest < Test::Unit::TestCase def setup @controller = AdminController.new .... get :index end def test_redirected_to_login assert ... end def test_warns_in_flash assert ... end def test_logs_unauthorized_access_to_admin assert ... end end class AuthenticatedAccessToAdminSectionTest < Test::Unit::TestCase def setup @controller = AdminController.new @request.session[:user] = ... get :index end def test_allows_access assert ... end end So, with TestInjector, my tests will still need to define @controller, right ? And reopen the right class ? Seems like your plugin would not be very good for me at this time. Unless there was a way it could get at the filename ? Probably not going to be easy. Thanks ! _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Is there a reason we don''t just create a new subclass of Test::Unit::TestCase called ControllerTest (or FunctionalTest) and inheirit from that instead? We don''t have to worry about the magic and it''s still backwards compatible. -- Kevin Clark http://glu.ttono.us
Not without even more magic. Test::Unit::TestCase has an inherited method that tries to build a test suite from any test_* methods in the subclass. Executing this code: require ''test/unit'' class FunctionalTest < Test::Unit::TestCase; end Produces: 1) Failure: default_test:2 No tests were specified. 1 tests, 1 assertions, 1 failures, 0 errors You could define a fake test, but then the test and assertion count will be off. Kevin Clark wrote:> Is there a reason we don''t just create a new subclass of > Test::Unit::TestCase called ControllerTest (or FunctionalTest) and > inheirit from that instead? We don''t have to worry about the magic and > it''s still backwards compatible. >
See ActiveRecordTestCase in active_record_unit.rb in actionpack. I defined a test_truth so Test::Unit::TestCase doesn''t complain. The test count is slightly inflated, but if you care enough about not having request, response and controller instance variables setup then it''s an option. Adding a default method is certainly less magic than guessing the controller name. -- Kevin Clark http://glu.ttono.us
Rails does a great job of inferring a lot of things based on names, so
it seems like a good fit to me.
class User < ActiveRecord::Base
has_many :assignments
end
From this class declaration, Rails infers that there is an Assignment
model that contains the foreign key user_id. Isn''t this the same kind
of "magic" we are talking about?
Kevin Clark wrote:> See ActiveRecordTestCase in active_record_unit.rb in actionpack. I
> defined a test_truth so Test::Unit::TestCase doesn''t complain. The
> test count is slightly inflated, but if you care enough about not
> having request, response and controller instance variables setup then
> it''s an option.
>
> Adding a default method is certainly less magic than guessing the
> controller name.
>
But the difference here is that has_many is named explicitly. The TestInjector (while cool, don''t get me wrong) feels a bit like PFM to save 3 lines in a setup method. It also encourages a 1 class to 1 test case method of testing which I don''t think always makes the most sense (see http://glu.ttono.us/articles/2006/08/07/why-fixtures-suck-and-how-we-can-fix-them for more on that). On 8/18/06, Keith Morrison <keithm@infused.org> wrote:> Rails does a great job of inferring a lot of things based on names, so > it seems like a good fit to me. > > class User < ActiveRecord::Base > has_many :assignments > end > > From this class declaration, Rails infers that there is an Assignment > model that contains the foreign key user_id. Isn''t this the same kind > of "magic" we are talking about? > > Kevin Clark wrote: > > See ActiveRecordTestCase in active_record_unit.rb in actionpack. I > > defined a test_truth so Test::Unit::TestCase doesn''t complain. The > > test count is slightly inflated, but if you care enough about not > > having request, response and controller instance variables setup then > > it''s an option. > > > > Adding a default method is certainly less magic than guessing the > > controller name. > > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Kevin Clark http://glu.ttono.us
On 8/18/06, Keith Morrison <keithm@infused.org> wrote:> You could define a fake test, but then the test and assertion count will > be off.A simple: def default_test end In your abstract test case will prevent the failure, and while you will see an extra test, there will be no assertion inflation. I know that the default_test is pretty much universally hated (Ryan Davis has a colorfully named test method in one of his base classes to prevent it from failing) and I agree that it is/was a bad idea. I''m working on something that I''m hoping will greatly improve the ability for frameworks like Rails to do "frameworky stuff" for testing without completely monkey-patching the testing framework. More details when I have something concrete to show. HTH, -- Nathaniel Talbott <:((><
* Posting on behalf of James Mead (jamesmead44@gmail.com) * Sounds interesting. I''ve been doing my own monkey-patching recently (http://mocha.rubyforge.org/classes/MultipleSetupAndTeardown.html) and have noticed a couple of other people (http://www.agilewebdevelopment.com/plugins/testcase_setup_and_teardown_with_blocks and http://mabs29.googlecode.com/svn/trunk/plugins/active_test/lib/active_test/base.rb) doing similar things. It would be really good to get support for multiple setup/teardown methods into the Test::Unit library. James. On 8/19/06, Nathaniel Talbott <ntalbott@gmail.com> wrote:> On 8/18/06, Keith Morrison <keithm@infused.org> wrote: > > > You could define a fake test, but then the test and assertion count will > > be off. > > A simple: > > def default_test > end > > In your abstract test case will prevent the failure, and while you > will see an extra test, there will be no assertion inflation. > > I know that the default_test is pretty much universally hated (Ryan > Davis has a colorfully named test method in one of his base classes to > prevent it from failing) and I agree that it is/was a bad idea. I''m > working on something that I''m hoping will greatly improve the ability > for frameworks like Rails to do "frameworky stuff" for testing without > completely monkey-patching the testing framework. More details when I > have something concrete to show. > > HTH, > > > -- > Nathaniel Talbott > > <:((>< > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core