I want to start with a kudos for writing tests.

I'm not that fond of Controller/Functional tests basically for this very reason:

Web applications contain a ton of context and setup. Controller/Functional specs can have so many paths that you can possibly take due to this and this is what leads to big, slow and hard to maintain test suites. Every time you add a new logical branch you now have another fork that you have to test for in N amount of places. Yikes, that sure gets out of hand quickly.

Try just writing Acceptance tests that follow the "happy path" that a User would go through. Also cover "unhappy paths" for mission critical tasks. Anything that a User will navigate in the UI belongs in an Acceptance and if you have some important non-UI tasks you can put those in a Request spec.

For even more testing boners: Write your tests first following an Outside-In pattern of: Acceptance -> Unit -> Implementation -> Refactor.

I agree that controller tests are of somewhat limited value, in particular because you'll have a ton of controllers and a ton of potential outcomes for each controller. The one I did test was one that had very complicated authorization logic, and would have required several different users of different roles to interact.

We're also not bothering to wire up the views right now because we have a UI guy coming in to redo the whole design/flow next week (we're a 3 person company, and I'm doing basically 90% of the site right now while we look for more people). So in this case I spent a bit of extra time on one controller spec, and am not 100% confident that it's secure/functional when we do go in and implement the views.

I don't imagine I'll have too too many controller specs, but will probably test some of the more complicated ones for certain actions.

I like the approach you laid out in the end. Once we have the flow laid out, I'll throw down a few feature/request specs. And of course we'll test the models thoroughly.

I look forward to refining my method of testing as we go forward (as I'm literally 8 days into my first full time rails job and I feel like I've learned a ton already). I can see how unbelievably valuable they are though even with a small suite.

I'm also a big fan of thoughtbot's shoulda matchers gem. Makes testing validations and relationships very fast and painless.

So "Learning Rails 3" and "Agile Rails Development" both kinda suck. Any other recs for good books / tutorials?

Was considering getting the Hartl screencasts...

They're definitely solid for a beginner... best intro book/tutorials I found.

Introduction to testing is very valuable.

Is the book basically the same as the screencasts? I guess I'm not clear what's better/diff from book to screeencasts...

I'm a noob but Agile Web Development with Rails is pretty good

Looking to create a simple database of a few different related items for private use. Is RoR a good choice to construct and present the data quickly?

Basically my friend has a bunch of craigslist accounts that he posts with. So I'd want to be able to present data about all the accounts on an overiew, then add new craigslist posts, etc

Here's a basic overview of the elements

Person
-name
-dob
-email
-password
-Craigslist Posts (one or more) (fk)
-Yelp Posts (one or more) (fk)
-VPN IP (fk)

Craigslist Post
-Datetime
-City
-Url

Yelp post
-Datetime
-Url

VPN Server
-Name
-Password
-IP[]
-cost

I think controller specs for important things like authorization/authentication are acceptable. Too much from there though and it's going to become a headache to maintain and really slow down your test suite.

I'm currently working along side thoughtbot on a project at my work. Their testing methods are very thorough and a bit different than what I've used in the pastbut it's been a great learning experience so far. thoughtbot is more thorough than I'm used to as I came up through the "37signals" stack of testing so seeing tests for things like model validations and associations was a bit strange at first.

I have grown to really enjoy shoulda and shoulda-matchers too though. There's a lot of magic going on in shoulda though so I suggest learning what's really happening at some point. We're also using this new level of abstraction called Experiences. It's for extracting behavior that you would use in your Feature/Acceptance tests into reusable objects in other Feature specs. So far I'm really enjoying that.

I remember when I was in your shoes. The early on learning experience is awesome. Days upon days of my head hurting from intense learning. Keep at it. As far as I can tell, testing is a life long journey.

I recommend books personally but that's just me and my attention span sucks for videos. Programming concepts + dry, boring voices puts me to sleep. I could never sit through DeucesCracked videos either.

For a first book I've always recommended Agile Web Development with Rails. It uses a "default" Rails stack so it's very approachable as opposed to other books that have you ripping out Fixtures and TestUnit before you even understand what they do.

I make the recommendation above assuming that you already know a bit of Ruby. If you don't, I recommend Chris Pine's excellent (and free!) Learn To Program followed by Russ Olsen's Eloquent Ruby.

So I have Agile Web Dev with Rails and don't like it *that* much. In general I'm not a big fan of books that teach you by creating one application and you "learn as you go"...

"The Rails 3 Way" is a bit advanced but my fav so far

Most introductory books are going to teach you by creating one application. Agile Web Dev with Rails third section takes a deep into ActiveRecord and ActionPack which I think is crucial for any beginner.

I've heard good things about The Rails 3 Way and many say it's a good Rails reference. As a reference though I've always found http://guides.rubyonrails.org to suffice or just the good ol' Rails API.

You just get more in depth, and see a real life workflow. Both of which are hard to replicate in a book.

Rails tutorial is really the only solid beginner resource out there that I found. Other books are good for a look after that one IMO.

Is there much value in learning raw SQL when learning Rails? Seems like Rails typically has more succinct commands for almost anything you'd wanna do in SQL...

It is possible that you will eventually hit something that cannot be done easily without raw SQL, or that would perform better with raw SQL.

SQL is pretty easy... but I've written raw SQL like 3 times in 15 months of using rails, so meh.

ORMs (like ActiveRecord, rails' database layer) can be very dangerous if you don't know how your commands are being translated into SQL or if you have no SQL knowledge. They'll come a time where you have enough data or are doing complicated enough things and queries will start slowing down. You need to have at least a cursory understanding of SQL databases for basic optimizations like adding an index.

SQL is definitely not easy but it's incredibly valuable to learn. If you have a slow response time, you have to be able to dump out the raw SQL and see what can be changed to improve the times. It's truly amazing how shifting a statement block can drastically improve or decrease the query times.

Considering the question, it sounds like having a solid grasp of SQL would be a huge advantage, especially if you eventually apply to a RoR house with no DBA.

I actually had a situation recently where I had to write some raw sql to model a relationship correctly, and wanted to see if anyone has a better solution.

These are the models I have:

class Suite

has_one :tenancy, order: 'tenancies.started_at DESC'
has many :past_tenancies, class_name: 'Tenancy'
has_one :tenant, through: :tenancy, order: 'tenancies.started_at DESC'
has_many :past_tenants, through: :past_tenancies, source: :tenant

class Tenancy

belongs_to :tenant
belongs_to :suite

class Tenant

has_many :tenancies, conditions: "tenancies.id IN (SELECT id FROM tenancies, (SELECT suite_id, MAX(started_at) as max_started FROM tenancies GROUP BY suite_id) active WHERE tenancies.suite_id = active.suite_id AND tenancies.started_at = active.max_started)"

has_many :past_tenancies, class_name: 'Tenancy'
has_many :suites, through: :tenancies
has_many :past_suites, through: :past_tenancies, source: :suite

A tenant can be occupying multiple suites at the same time. I'm using a join model, Tenancy, to relate the two and determining which is the active tenancy for a suite by selecting the tenancy with the most recent started_at time.

The issue is that to get all of a tenants suites that he is currently occupying, I need to get the most recent tenancy for each suite and then select the ones that are his.

Some of the other options I considered are -

1. Adding an active_tenant_id field to the Suite model
2. Adding an active field to the tenancy relationship
3. Writing the SQL with arel ( I couldn't figure out how after limited research, anyone know what this would be? )

Out of the solutions I came up with, I chose mine because it has the least additional overhead - I just set the started_at appropriately and the rest is taken care of.

BTW, in case it's not clear, I use a has_one on Suite with an order clause as a hack to grab the current tenancy/tenant - the SQL generated just tacks on a LIMIT 1. For some reason, though, the order clause gets dropped on the through relation, so I have to specify it again.

My first thought is:

Suite
id

Tenant
id

Tenancy_Current
suite_id
tenant_id

Tenancy_History
suite_id
tenant_id

I find that a lot of the time with situations like these you only want current Tenants 99% of the time, but have to keep track of the whole history for that 1% case. For that case I'd think a separate history table would be easier.

If you're absolutely sure a Suite can only have one current tenant, you could put that current tenant as a field in the suite model as it is a one to many relationship. From a real world point of view though that seems a little dangerous - what if two people are sharing a suite?

You're comment about the current vs past tenants is spot on.

There will only ever be one tenant per suite - the suites are actually sub-units of a Facility class that I excluded. The only other piece of information I store in the tenancies table is the starting date, so I would have to move that to suites along with the tenant_id.

Will have to think more on separating out a tenancy history table; it seems to me to be equivalent of adding an active field on the tenancy table, albeit with a performance boost.

Sounds like the root problem is the lack of an end timestamp in the tenancy model. Having this makes it trivial to separate things into past/current and cleans up your APIs. You also can't model vacant suites without it, which sounds like something you should be able to do.

I actually do have an end datetime on tenancies but it doesn't help the issue. I want to avoid using scopes because you lose a lot of rails magic when you use them instead of going through the relationship helpers.

Zeus is the best gem ever. Makes all the rails command for our bloated app super fast, tests are lightning.

Tests would take about 15 seconds to boot up without it, now they boot up in less than a second. Makes testing way less of a pain. I also configured it to run in sublime with rubytest so I can run a console within sublime.

Haha sick.

Anyone know of good resources/tutorials on dealing with Ajax / sending info back as json and manipulating that data?

Am using nokogiri to scrape a site but am a bit frustrated trying to sort out exactly how to deal with the info coming back...

The Rails 3 Way. It is in depth and good reference. Goes into some Rails internals.

BTW, anyone play around with Rails 4 with Ruby 2.0? Crap this stuff changes so quickly. How long until Rails 3 becomes obsolete. If you're starting a new hobby app is there any benefit to sticking with Rails 3?