rspec users - Oct 2011 - Override tests (of a core rails app from a plugin)

Hello,

Is there some way to override a spec and more specifically parts of spec,
ideally down to a specific example? I''ve been looking and googling for
something like this, but I haven''t found a good strategy for it.

The use-case is for a rails app that supports plugins, and those plugins may
also tweak the behavior of core objects. For example (and it is a simplistic and
bad example, but bear with me): Suppose a User object that has a boolean
attribute show_mail_address that controls if the mail address of the user can be
shown publicly, and that this defaults to true in the core app, but a
security-savvy user of the software doesn''t want that and creates a
plugin to change the default to false. Running the core tests with the plugin
will fail because the default won''t be the one the tests expect. Is
there any way to selectively override examples/tests/groups and/or extend tests
(in the case the plugin adds functionality to the core object)?

Thanks,

Felix

On Oct 1, 2011, at 7:03 AM, Felix Sch?fer wrote:
> Hello,
> 
> Is there some way to override a spec and more specifically parts of spec,
ideally down to a specific example? I''ve been looking and googling for
something like this, but I haven''t found a good strategy for it.
> 
> The use-case is for a rails app that supports plugins, and those plugins
may also tweak the behavior of core objects. For example (and it is a simplistic
and bad example, but bear with me): Suppose a User object that has a boolean
attribute show_mail_address that controls if the mail address of the user can be
shown publicly, and that this defaults to true in the core app, but a
security-savvy user of the software doesn''t want that and creates a
plugin to change the default to false. Running the core tests with the plugin
will fail because the default won''t be the one the tests expect. Is
there any way to selectively override examples/tests/groups and/or extend tests
(in the case the plugin adds functionality to the core object)?
> 
> Thanks,
> 
> Felix
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
Specs do not over-ride each other, so I can''t think of an easy to do
what you''re trying to do. With that said, I have never come across a
situation like this because usually the app has one or the other.
Shouldn''t the user delete their own code that your plugin accomplishes
after they install it? Or, maybe your plugin overrides their core functionality,
but doesn''t provide tests - in which case it''s up to the user
to adjust their tests to your plugin.

Am 01.10.2011 um 22:17 schrieb Justin Ko:
> Specs do not over-ride each other
That''s what I was able to gather so far, unfortunately.
> , so I can''t think of an easy to do what you''re trying to
do. With that said, I have never come across a situation like this because
usually the app has one or the other. Shouldn''t the user delete their
own code that your plugin accomplishes after they install it? Or, maybe your
plugin overrides their core functionality, but doesn''t provide tests -
in which case it''s up to the user to adjust their tests to your plugin.
The point is that a plugin can change core code but not core tests, making the
core tests virtually useless. I''m aware that the preferred solution
would probably be to test the core app and the plugins independently, or at
least that the plugins only test what they change so that you could say "if
the core tests without the plugin and the plugin tests with the plugin work,
everything is fine", it doesn''t work that well though. Changes
introduced by plugins might slightly change other behaviors and have unintended
(and thus not tested by the plugin''s tests) side-effects which the core
tests might catch, if those are known to break because of intentional changes to
the core by the plugin, they''re of no use.

Felix

I''m not sure what you mean by "core code" and "the
user" here. Are you
writing an app, or a library, or a plugin? If you''re writing an app,
you
should test the app''s behavior, which includes all the plugins and
however
you configured them; if you''re writing a library you should have
scenarios
that test the various configuration options and basic functionality.

If you''re writing a Rails plugin, you should test how that plugin works
inside apps. One way to do this is to generate some toy rails apps, stick
them deep inside your "spec" directory somewhere, have them include
your
plugin and configure it in various ways, then test that the toy apps perform
as expected. (Technically those would be integration tests, not unit tests,
and you don''t want to write too many of them if you can test the bulk
of
your code through unit tests.)

you could say "if the core tests without the plugin and the plugin
tests
> with the plugin work, everything is fine", it doesn''t work
that well though.

If your app is using a plugin, then why (and how) would you ever test your
app without the plugin?

-- 
Alex Chaffee - alex at stinky.com
http://alexchaffee.com
http://twitter.com/alexch
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20111002/0e256164/attachment.html>

On Sun, Oct 2, 2011 at 11:57 AM, Felix Sch?fer <f.schaefer at finn.de>
wrote:
>
> Am 01.10.2011 um 22:17 schrieb Justin Ko:
>
>> Specs do not over-ride each other
>
> That''s what I was able to gather so far, unfortunately.
>
>> , so I can''t think of an easy to do what you''re
trying to do. With that said, I have never come across a situation like this
because usually the app has one or the other. Shouldn''t the user delete
their own code that your plugin accomplishes after they install it? Or, maybe
your plugin overrides their core functionality, but doesn''t provide
tests - in which case it''s up to the user to adjust their tests to your
plugin.
>
> The point is that a plugin can change core code but not core tests, making
the core tests virtually useless. I''m aware that the preferred solution
would probably be to test the core app and the plugins independently, or at
least that the plugins only test what they change so that you could say "if
the core tests without the plugin and the plugin tests with the plugin work,
everything is fine", it doesn''t work that well though. Changes
introduced by plugins might slightly change other behaviors and have unintended
(and thus not tested by the plugin''s tests) side-effects which the core
tests might catch, if those are known to break because of intentional changes to
the core by the plugin, they''re of no use.
>
So, what you are saying is that you don''t know how the core is
supposed to work after the user modifies it. So, you can''t test that.
But, you need the core tests to prove that it works after they modify
it (Although, you don''t know how it will work then.)

:-(

What you want seems like a logical impossibility to me.