Am I off track on my testing?

Is it just me or does anyone else miss being able to create something
quickly. Once you start writing all the tests your time is now
increased by a factor of 10. I agree with the logic in testing, but am
I doing something wrong?

Take the simple example of a controller test for an index action that
shows all the forum posts for a user account.

The controller code would be something like what is shown below, and on
a bad day may take a minute to do (a really bad day)

before_filter :login_required
before_filter :find_account

def index
@posts = @account.posts
end

Now the controller tests are as following, and with the make it fail,
make the update, make it pass strategy would could take about 10
minutes.

describe PostsController, “index” do

before :each do
@posts = mock(“posts”)
@account.stub!(:posts).and_return(@posts)
end

it “should call the find account method” do
controller.should_receive(:find…
do :get
end

it “should assign the @account model” do
do :get
assigns[:account] …
end

it “should call the login required” do
controller.should_receive…
do :get
end

it “should call on the account.posts” do
@account.should_recei
get :index
end

it “should assign posts” do
do_get
assigns[:posts]…
end
end

=========

Now this is a simple example, but that is a lot of extra tests for three
lines of code. I don’t know if it is just me, but it takes away some of
the fun in being able to see results right away.

I understand that with more complex code it may be easy to make a change
that could have unexpected effects elsewhere. In the above example,
there is no logic that would ever get changed by accident on later
updates at least not by anyone who knows what they are doing.

Maybe I am way out in left field with the tests that I write, but the
tests above are done using the fails, update, pass sequence. I just
can’t see the reasoning for writing all these tests for something so
simple.

I guess my thing is that I like writing tests when they will eliminate a
lot of manual testing ex automated scheduling class. This would require
a lot of different tests to make sure that the scheduler works as it
should. I also don’t have a problem with model testing seeing as there
may be some logic within the model that is unique to it. I do find view
testing to be a very unenjoyable, and I haven’t event looked at stories
yet.

I am not trying to say that testing isn’t good and that everyone is on
the wrong track, but rather wondering if, as in the example, am testing
more than I should be.

Thanks

A couple comments inline…

On Thu, Mar 13, 2008 at 5:54 PM, __iso __ [email protected] wrote:

it “should call the login required” do
controller.should_receive…
do :get
end

This is testing too much. Just stub the call to logged_in? or whatever

it “should call on the account.posts” do
@account.should_recei
get :index
end

There’s no need for this. If your mocks are set up properly, then the
only way for assigns[:post] to == your mock list of posts is if
@account receives #posts. So this example duplicates some of the
stuff that’s implicitly tested in the next one, which is a much more
useful example.

it “should assign posts” do
do_get
assigns[:posts]…
end
end

> > I am not trying to say that testing isn't good and that everyone is on > the wrong track, but rather wondering if, as in the example, am testing > more than I should be.

Personally, I write tests when I feel that they will help me design my
code better, give me confidence that the code works as expected, or
serve as useful documentation. If you aren’t benefiting from certain
tests, then don’t write them (gasp)

Remember, BDD isn’t some magical routine that, if followed, leads to
perfect applications. It can be very helpful in achieving certain
desirable ends, but it’s not a substitute for your own thinking.
Pragmatism and creativity reign supreme.

Lately I’ve started to write fewer interaction-based specs (like the
example you gave) when dealing with controllers. I tend to just make
the request and let it go all the way down to the database, to make
sure that everything is hooked up properly. The catch is that your
controllers have to be super skinny - you should be able to cover an
action with one or two examples - and have the majority of
permutations be handled by the model (and thus covered with model
specs).

Pat

Thanks for the info Pat. To be honest that is what I wanted to hear.
There seems to be such an importance set on the lines of code to lines
of testing ratio that it seems a person is violating some rule if the
ratio isn’t high enough to the right.

The thing that bugged me when writing out the tests for controllers is
that there really was no logic in the controller code. It looked just
like 90% of the controllers I have created, so it made no sense to why I
had (or so I thought) to write so many tests.

It seems that most tests are written in the fear that someone will later
make a change and not realize what they have done unless a test now
fails. For example in model testing I am sure most people create a
tests for the relations to other models, but for what reason. You write
the test to whether the relation exists, it fails, you make the
relation, it passes. Why not just write the relation and be done with
it, because there is paranoia that someone will later decide to delete
the relation…I guess. The same is also true for testing if there the
various validators exist for the various columns.

As I mentioned before, I am totally in favour of writing tests where
there is some fear that it may not work as I expected, for that tests
rock. It is the tests that acts as a double check that I don’t care for
so much. Maybe the book below that amazon displays on main page every
time I visit the site should be something I check out soon.

Thanks again Pat.

http://amazon.ca/gp/product/0321146530/ref=s9_flash_asin_image_1_wish_c2?ie=UTF8&coliid=I2GQJNWRWB147V&colid=7OMS5OB238SP&pf_rd_m=A3DWYIK6Y9EEQB&pf_rd_s=center-2&pf_rd_r=1Z4Z31VY2YQ6P9PHQSK6&pf_rd_t=101&pf_rd_p=289767901&pf_rd_i=915398

On the other hand, earlier today my pair and I had to override a
find_by_param method. We quickly wrote it down:

def find_by_param(val)
find_by_id val
end

We were puzzled, then saw that it should be User.find_by_param.

Who’da thunk.

Pat

On Thu, Mar 13, 2008 at 10:42 PM, __iso __ [email protected] wrote:

Maybe the book below that amazon displays on main page every
time I visit the site should be something I check out soon.
http://amazon.ca/gp/product/0321146530/ref=s9_flash_asin_image_1_wish_c2?ie=UTF8&coliid=I2GQJNWRWB147V&colid=7OMS5OB238SP&pf_rd_m=A3DWYIK6Y9EEQB&pf_rd_s=center-2&pf_rd_r=1Z4Z31VY2YQ6P9PHQSK6&pf_rd_t=101&pf_rd_p=289767901&pf_rd_i=915398

Yes, you should

Is it just me or does anyone else miss being able to create something
quickly.

When I write customer paid for software I strive to apply the best
practices to ensure they have high quality, low bug software which is
well-factored with the goal that it is easier to maintain and extend
over its lifetime, assuming there will be developers added to the
project over its lifetime that were not there for its original
development efforts.

When I write software for myself I tend to flip flop. Sometimes I am
writing things to learn or play and I don’t test. Sometimes I want to
work on my ability to write well designed testable software, so I do
test.

Also, don’t forget that sometimes when producing software you need to
SPIKE some things out, which means you code upfront to investigate
(kind of like prototyping) and then when you figure out what you want
to do, or how-to do it you scratch the prototype and reimplement
w/tests.

Once you start writing all the tests your time is now
increased by a factor of 10.

Here’s another perspective to look at it from. When you write testable
and tested software you spend less time coming back to it to track
down and fix erroneous bugs. There is a much higher risk you will have
to track down and fix erroneous bugs when you don’t test (or don’t
test well there is a difference).

There are also the things to account for like when you design for
testability and the fact that you usually end up with simpler
components which are easier to add to, extend or change. So as your
program grows and changes from your customer’s perspective you are
able to maintain fluid momentum for changing the code as well. When
you don’t test there is usually a lot of momentum in the first few
weeks, but then development slows down and even comes to a halt
because the codebase is not well factored, and bugs are much more
easily introduced with these changes and you spend more time tracking
down bugs, fixing bugs and trying to understand the codebase.

So I don’t agree with the factor of 10 because when you don’t test you
spend a lot more time over the life of the project tracking down bugs,
fixing bugs, and a much more difficult time changing the codebase to
grow with its users needs and your customers desires. All of the time
spent doing these things should be added to the time it took to
originally develop a feature upfront since it really wasn’t done.

People also have different levels of software development skills
(design, testing, object decomposition, etc) and they can produce
things at different speeds so a factor of 10 for you may be a factor
or 0 for someone else.

before_filter :find_account

end

=========

Now this is a simple example, but that is a lot of extra tests for three
lines of code. I don’t know if it is just me, but it takes away some of
the fun in being able to see results right away.

First thing: do not stub or mock expect the object under test.

When you’re testing a controller do not “stub!” the controller and do
not
“should_receive” the controller. This removes the value you get for
testing
the controller itself. There are exceptions to this rule, and this is
largely
because people violate the use of mixins. That is for another
conversation though.

I know that Pat said that the
“controller.should_receive(:login_required)” is
too much testing, but I’m going to be more forward. It is not too much
testing,
it is testing the wrong thing.

I understand that with more complex code it may be easy to make a change
that could have unexpected effects elsewhere. In the above example,
there is no logic that would ever get changed by accident on later
updates at least not by anyone who knows what they are doing.

Maybe I am way out in left field with the tests that I write, but the
tests above are done using the fails, update, pass sequence. I just
can’t see the reasoning for writing all these tests for something so
simple.

So when the application gradually becomes more complex do you think
you’ll eventually
get to a point and say, “well I need to test this now?”. Unfortunately
even if you do
do that when you get to point there’s a really good chance you didn’t
write the code
for testability, so the barrier to test is much higher, and it’s
easier for people to
give in and not test at this point because it’s now to difficult to
test, and they can’t
spend a long time fixing bad code they’ve written.

I guess my thing is that I like writing tests when they will eliminate a
lot of manual testing ex automated scheduling class. This would require
a lot of different tests to make sure that the scheduler works as it
should. I also don’t have a problem with model testing seeing as there
may be some logic within the model that is unique to it. I do find view
testing to be a very unenjoyable, and I haven’t event looked at stories
yet.

Testing is not about developer enjoyment. It’s about producing high
quality
low bug software in a way that allows you to sustain a consistent
development
pace over the lifetime of the project.

Although I do get enjoyment knowing I’m producing high quality software.

I am not trying to say that testing isn’t good and that everyone is on
the wrong track, but rather wondering if, as in the example, am testing
more than I should be.

I think you’re experiencing growing pains. Thank you for posting your
concerns and questions. I used to have some of the same questions
you’re having. Hopefully
my response has been helpful to raise some counter arguments to your
concerns,

Zach D.
http://www.continuousthinking.com

I really agree with the topic starter. I’ve always done the rspec
testing
with all layers in isolation, a bit like the first example.
Now for my latest project I went a bit for a more TDD approach, sending
a
request to a controller and testing the full stack, including the
dynamic
bits of the layout.
It really helped me getting a quick start.
Now I don’t know how this will work out on the long term, I’ll probably
write some additional tests on the model level to assure workings with
different variables.

I found out that I was wasting way too much time trying to practise and
especially trying the come up with the best theory behind BDD, while I
just
should have get started and make things work.

Zach D. wrote:

When I write software for myself I tend to flip flop. Sometimes I am
writing things to learn or play and I don’t test.

I did that on a recent small project and I was amazed at how fast I was
able to get things done.

Here’s another perspective to look at it from. When you write testable
and tested software you spend less time coming back to it to track
down and fix erroneous bugs. There is a much higher risk you will have
to track down and fix erroneous bugs when you don’t test (or don’t
test well there is a difference).

One of the issues that I have had a couple times is that since I am
writing the tests and the corresponding code in a serial fashion,
sometimes my mind is off tangent and I write a test that is incorrect, I
then write the corresponding code to allow the incorrect test to pass.
And voila I have given myself confidence that everything is in working
order since I tested it, but it is wrong.

I believe, that one of the reasons for this is that I am writing too
many tests, and because of that the tests start to lose their meaning.
The tests become a series of tasks that I hastily try to place a check
next to so I can feel I am working efficiently and move on to the next
one. I think cutting down on the number of tests I write will allow me
to better ensure the tests I have are required and correct.

I am beginning to think that if a person checks the code to test code
ratio more than once a week they may be testing for the wrong reason.

First thing: do not stub or mock expect the object under test.

When you’re testing a controller do not “stub!” the controller and do
not
“should_receive” the controller. This removes the value you get for
testing
the controller itself. There are exceptions to this rule, and this is
largely
because people violate the use of mixins. That is for another
conversation though.

What would you recommend instead? Since the before_filter contains a
login_required check I have to stub something to allow the test to be
completed.

So when the application gradually becomes more complex do you think
you’ll eventually
get to a point and say, “well I need to test this now?”. Unfortunately
even if you do
do that when you get to point there’s a really good chance you didn’t
write the code
for testability, so the barrier to test is much higher, and it’s
easier for people to
give in and not test at this point because it’s now to difficult to
test, and they can’t
spend a long time fixing bad code they’ve written.

Good point. I guess my confusion is to whether testing should exist
where there is really no logic. Take an update controller method:

@user = User.find(params[:id])
if @user.update_attributes(params[:user)
flash[:success] = “…”
redirect_to admin_users_url
else
render :action => :index
end

Pretty simple stuff. Is it worth 40 lines of test code? That is what I
am wondering, because I don’t think so.

Testing is not about developer enjoyment. It’s about producing high
quality
low bug software in a way that allows you to sustain a consistent
development
pace over the lifetime of the project.

I find that the issue with writing more tests than are required is that
things become more brittle. One small change results in 10 failed tests
and 20 minutes of work to clean up, and that is not enjoyable. I think
that writing tests should be enjoyable since that is what it takes for
me to keep doing them.

I think you’re experiencing growing pains.

Adolescence all over again :slight_smile:

Thank you for posting your

concerns and questions. I used to have some of the same questions
you’re having. Hopefully
my response has been helpful to raise some counter arguments to your
concerns,

Input from experienced people always allows me to look at things from a
different angle.

Thanks Dennis.

On Fri, Mar 14, 2008 at 2:08 PM, __iso __ [email protected] wrote:

down and fix erroneous bugs. There is a much higher risk you will have
I believe, that one of the reasons for this is that I am writing too

What would you recommend instead? Since the before_filter contains a
login_required check I have to stub something to allow the test to be
completed.

I typically test filters by themselves, and then stub out the filters
when testing the action, so there is a clear separation between the
two. For logins I use a helper to ensure that a controller/action is
requiring login if necessary.

describe SomeController, “#index” do
it_requires_login :get, :index
end

Then when testing the action itself I do stub all before filters,
because I have already tested them elsewhere. If the action requires
login I have a login_with_user helper which sets the logged in user to
some mock User and then returns it so I can use it in my test. LIke
below:

describe SomeController, '#index" do
def get_index
get :index
end

before do
   stub_before_filters!
   @user = login_with_a_user
end

...

end

test, and they can’t
render :action => :index
end

Pretty simple stuff. Is it worth 40 lines of test code? That is what I
am wondering, because I don’t think so.

Can someone change this implementation and still have your tests pass,
but have the implementation be broken? If they can then yes it is
worth the 40 lines.

Pat mentioned that he uses very skinny controllers and does
integration tests which go through the whole stack to make sure things
work. So if he doesn’t test the controller#action’s because they are
too simple he at least will have a failing integration test if someone
breaks the implementation.

The problem I have with what Pat is doing is that it takes a lot of
discipline from the developer to not let the controller grow into a
cesspool of logic and interaction that shouldn’t be there, but you put
it there because you aren’t “testing” it directly. From what I’ve seen
most Rails apps have important interaction in the controller actions
and logic in the before filters. I would not personally take this
approach on customer paid for software. Pat may be more disciplined
then me though. =)

Testing is not about developer enjoyment. It’s about producing high
quality
low bug software in a way that allows you to sustain a consistent
development
pace over the lifetime of the project.

I find that the issue with writing more tests than are required is that
things become more brittle. One small change results in 10 failed tests
and 20 minutes of work to clean up, and that is not enjoyable.

If a change to one object results in multiple failing integration
tests, then that is awesome because you know exactly what you broke
with that change. If that change breaks a bunch of model, controller,
etc specs then how there is an issue in how you’re testing.

I think
that writing tests should be enjoyable since that is what it takes for
me to keep doing them.

Testing is a skill to be learned. I get a lot of enjoyment out of
producing high quality software for my customers. Testing reinforces
that I do just that. I also get enjoyment out of finding better ways
to write software which makes them more easily testable. If you’re
looking for the instantaneous gratification that you get with hacking
something together real quick then you’re not going to find that with
testing. If that’s your motive for writing tests then you’re writing
tests for the wrong reasons.

concerns,

Input from experienced people always allows me to look at things from a
different angle.

Thanks Dennis.

Dennis my last name. Zach is my first name :wink:

On Fri, Mar 14, 2008 at 6:08 PM, Zach D. [email protected]
wrote:

most Rails apps have important interaction in the controller actions
and logic in the before filters. I would not personally take this
approach on customer paid for software. Pat may be more disciplined
then me though. =)

The way to do this is to not put any business logic in the action, and
the way to do THAT is to metaprogram the action away.

Our controllers look like this:

class PostsController < ApplicationController
actions :show, :new, :create
end

with hooks for stuff like on_successful_create if the default behavior
isn’t sufficient.

It feels pretty radical at first, but it just takes a bit of
creativity to make it work. I find it to be a very elegant approach.

Pat

Zach D. wrote:

Can someone change this implementation and still have your tests pass,
but have the implementation be broken? If they can then yes it is
worth the 40 lines.

It is partly this paranoia of someone changing the code that makes me
question testing of this magnitude. Other than attaching files if a
file was uploaded I have yet to have any real logic in my controllers,
so I can’t imagine why I would change anything, but maybe that is how it
all starts :slight_smile:

The problem I have with what Pat is doing is that it takes a lot of
discipline from the developer to not let the controller grow into a
cesspool of logic and interaction that shouldn’t be there, but you put
it there because you aren’t “testing” it directly. From what I’ve seen
most Rails apps have important interaction in the controller actions
and logic in the before filters. I would not personally take this
approach on customer paid for software. Pat may be more disciplined
then me though. =)

I guess that is where I am blind, as I don’t have any apps that have
reached the point of “additional functionality” yet.

If a change to one object results in multiple failing integration
tests, then that is awesome because you know exactly what you broke
with that change. If that change breaks a bunch of model, controller,
etc specs then how there is an issue in how you’re testing.

After writing a lot of tests I began to think that taking more of a
black box approach, ie test what goes in and what comes out, is the best
way in that it allows me to make changes inside the box, without having
to pick up the pieces of all the broken tests.

Dennis my last name. Zach is my first name :wink:

:slight_smile: Sorry about that, I figured that out right after I posted. Somehow I
saw Dennis and that is what registered upstairs.

Zach D. wrote:

The problem I have with what Pat is doing is that it takes a lot of
discipline from the developer to not let the controller grow into a
cesspool of logic and interaction that shouldn’t be there, but you put
it there because you aren’t “testing” it directly. From what I’ve seen
most Rails apps have important interaction in the controller actions
and logic in the before filters. I would not personally take this
approach on customer paid for software. Pat may be more disciplined
then me though. =)

I totally agree with this point. Using interaction-based testing really
helps in forcing the logic down into the model.

I’m curious about your comment: “From what I’ve seen most Rails apps
have important interaction in the controller actions
and logic in the before filters”. What are you exactly referring to? I
generally use before filters for authentication… How have you seen
them abused?

-Ben

Lately I’ve started to write fewer interaction-based specs (like the
example you gave) when dealing with controllers. I tend to just make
the request and let it go all the way down to the database, to make
sure that everything is hooked up properly. The catch is that your
controllers have to be super skinny - you should be able to cover an
action with one or two examples - and have the majority of
permutations be handled by the model (and thus covered with model
specs).

isn’t sufficient.

I’ve been doing this for several months, ever since I started to use the
make_resourceful plugin. There are several plugins that have this
similar goal. The only downside I have run into with this approach is
that people newer to rails and MVC in general have a very hard time
figuring out what is going on. It is a layer of abstraction that is not
for the faint of heart or inexperienced. Other than that I love the
approach.

It feels pretty radical at first, but it just takes a bit of
creativity to make it work. I find it to be a very elegant approach.

I am interested why having this approach has motivated you to take more
of a state based approach on testing controllers.
Assuming that you have other integration tests (stories) that test the
full stack then having the controller specs hit the DB doesn’t seem to
buy you much and will slow your tests down quite a bit as compared to
the interaction-based approach. I know you know this already so I am
trying to understand how this newer way of writing controllers is more
suited for allowing the specs to hit the db. Skinny controllers have
been common practice for quite a while so I don’t see how the layer of
abstraction of declaring actions like above really changes things on the
testing level. Do you feel that interaction-based specs on the
controllers are too brittle… or verbose… or what?

Thanks for sharing :slight_smile:

-Ben

On Sat, Mar 15, 2008 at 2:38 PM, Ben M. [email protected] wrote:

testing level. Do you feel that interaction-based specs on the
controllers are too brittle… or verbose… or what?

At work where we’re doing this, we don’t use stories. So our
controller specs act as the integration tests. I think if we were
using stories, we likely wouldn’t have controller tests at all. Not
too sure about that though.

Another major reason for not using interaction-based tests is that all
of the controllers are identical, so any specs we write are just
testing framework code. No sense in that.

Pat

On Sat, Mar 15, 2008 at 5:43 PM, Ben M. [email protected] wrote:

I totally agree with this point. Using interaction-based testing really
helps in forcing the logic down into the model.

I’m curious about your comment: "From what I’ve seen most Rails apps

have important interaction in the controller actions
and logic in the before filters". What are you exactly referring to? I
generally use before filters for authentication… How have you seen
them abused?

I’ve seen before filters be abused. Authentication is typical an
application level responsibility and it makes sense for the controller
to protect its resources. No qualms there. I have inherited code bases
which abused before filters for things like checking permissions for
business requirements. For example:

class ProjectsController < ApplicationController
before_filter :login_required # i’m ok with this
before_filter :ensure_project_manager, :only => [:new, :create]
before_filter :ensure_project_write_access, :only => [:edit,
:update]
# … I’ve seen this filter list go on and on and on, based on
any possible persmission

I would rather introduce a Manager/Service object which is responsible
for accessing a project, and allow that do handle the responsibility
for knowing what permissions allow someone to create or edit a
project.

I’ve been experimenting with using an approach similar in spirit to
what Pat is doing, but slightly different:

class ApplicationController < ActionController::Base
rescue_from AccessDenied, ResourceNotFoundError do |exception|
redirect_to “/access_denied.html”
end
# …
end

class ProjectsController < ApplicationController
before_filter :login_required

def new
  @project = ProjectManager.new_project
end

def create
  ProjectManager.create_project params[:project] do 

|project_creation|
project_creation.success do |project|
flash[:notice] = “Project created successfully”
@project = project
end

    project_creation.failure do |project|
      flash[:notice] = "Project creation failed"
      @project = project
      render :action => "new"
    end
end
# ...

end

I tend to like this for projects I’ve worked on where it doesn’t make
sense to shove all of the responsibility onto a model because it
abstracts out the “Manager” who is in charge of ensuring permissions
and doing odds and ends things involved in the creation of a project
that the model should not be doing (like upload an associated picture
of the project manager or ensure memberships status).

In the above approach the application controller is setup to rescue
from certain application exceptions, and the controllers just do their
thing, and the managers which enforce the business logic will throw
the exceptions it a business rule has been violated.

On Sat, Mar 15, 2008 at 4:56 PM, Pat M. [email protected] wrote:

At work where we’re doing this, we don’t use stories. So our
controller specs act as the integration tests. I think if we were
using stories, we likely wouldn’t have controller tests at all. Not
too sure about that though.

This should be “I’m not 100% sure about that though”

Zach D. wrote:

too simple he at least will have a failing integration test if someone

them abused?
before_filter :ensure_project_manager, :only => [:new, :create]
before_filter :ensure_project_write_access, :only => [:edit, :update]
# … I’ve seen this filter list go on and on and on, based on
any possible persmission

Ahh, yes… I have seen this before. In fact people have told me that
they don’t test there controllers because of such permutations that take
too long to test fully (because they have to test it on EVERY controller
with those set of filters). Thats when I tell them that if things are
too hard to test that is probably a good sign the are doing something
wrong. :slight_smile:

In the past I have always pushed this in the model. I have ofter though
just let the controller call one simple predicate method on the model in
a filter. So perhaps I am guilty of abusing filters as well…

I would rather introduce a Manager/Service object which is responsible
for accessing a project, and allow that do handle the responsibility
for knowing what permissions allow someone to create or edit a
project.

Makes sense- I really like that idea. Having a service handle all of
this makes a lot of sense the more I think about it. As I have
developed rails apps I always keep my controllers extremely thin but
certain models become too large, IMO. I’ve actually been reading DDD
and have been trying to think of ways of creating more service objects
to remove the extra responsibility I have added in my models. Thanks
for pointing this one out to me.

class ProjectsController < ApplicationController
@project = project

I tend to like this for projects I’ve worked on where it doesn’t make
sense to shove all of the responsibility onto a model because it
abstracts out the “Manager” who is in charge of ensuring permissions
and doing odds and ends things involved in the creation of a project
that the model should not be doing (like upload an associated picture
of the project manager or ensure memberships status).

Very nice… I will definitely steal that slick use of blocks :wink:

My one question about this implementation is how does the ProjectManager
get access to the session or at least gets the information about the
current user? Without that information you can’t have any permissions
logic in the manager…

In the above approach the application controller is setup to rescue
from certain application exceptions, and the controllers just do their
thing, and the managers which enforce the business logic will throw
the exceptions it a business rule has been violated.

I have used a similar approach in apps in the past (by throwing an
AccessDenied exception), but I have somewhat gone away from that. My
hesitation was caused by me wondering if a violation of these
permissions really deems an exception. Is having a user trying to get
into an area where they don’t have the needed rights exceptional? So
seeing you use this same pattern makes me think that it probably is a
good use of exceptions. Having the logic in a manger I think the only
way to handle incorrect permissions cleanly would be an exception so I
guess the argument is somehwat moot in this context.

Thank so much for taking the time to answer my question. I always learn
a great deal from this list so thank you for contributing so much to it.

-Ben

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs