Writing specs pointed out I need to refactor my admin area


#1

Hi,

My app now nearly has 100% coverage and when refactoring the code,
potential bugs are immediately pointed out. So that’s a big win.

Moreover when writing specs for my controllers and views of the admin
zone, I quickly realized that I was often copying/pasting code and
tests. That annoyed me. Controller LOC: 700, associated tests LOC:
1500!!! That’s stupid!

So I wrote an AdminController from which my other controllers inherit
from, and that enables me to drastically cut down the lines of redundant
code in the controller. But then what to do with the views? I still need
to make sure they get rendered correctly, so I still can cut down on the
tests.

One solution I see is to write an abstract set of views that controllers
will be using, but for some reason I think it will blow in my façe at
some point. Some views need to display images others don’t, some display
a table others don’t, etc.

What do you guys do for your admin zone to make sure it is well covered
with tests and that don’t feel redundant? Do you use something like
Steamlined or ActiveScaffold?

Regards,


#2

So I tried to implement Django’s AutoAdmin, but actually it quite
quickly blew in my face. Although the views all look similar, there
almost as many little differences as they are models and that’s painful
to abstract. So I prefer to write my views for each model.

Now I have another problem, so my models are fully covered, my
controllers too, but what prevents my views from having for instance an
incorrect form that would be posting incorrect parameters to my
controllers? How do you test that? Cucumber + Webrat?


#3

2009/5/24 Fernando P. removed_email_address@domain.invalid:

Posted via http://www.ruby-forum.com/.


rspec-users mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/rspec-users

I use a combination of convention and cucumber stories using tables.

Convention sets up how a resource will be rendered in the various admin
views. I use classes and a forked version of webrat to detect them. So
my
structure will be (using HAML)

index

.resources

table headers

.resource
tr.fieldname0
tr.fieldname1

show

.resource
ul
li.fieldname

Then I test this using cucumber tables e.g

Scenario Outline: Admin can view resources
Given there are 3
When I goto admin_
Then I should see a list of

Examples:
| collection | object |
| categories | category |
| customers | customer |
| feeds | feed |

I extend this approach to access. It might be feasible in some way with
editing and creation, but I haven’t tried that yet.
This approach obviously doesn’t scale to more than about 10 admin
resources,
so whilst it will do for now if anyone has any better ideas … :slight_smile:

HTH

Andrew