Damnit, I'm tired of testing!

I lied!  I love it and it's totally helpful in the long-run.

Bryan Liles came up with a cool acronym -- TATFT (test all the fucking time).  As soon as I heard him talk about this at ActsAsConference2008, he instantly made the best possible answer to testing.  It doesn't matter what framework you write your tests in as long as you write tests.

Below are some quick guidelines for your tests to try to make it easier for those that are getting stuck as to "how to test" or "what should my tests contain for this type of test".  By no means are they the answer to all your problems, but somewhere that you can build off of:

Model tests:

• In rails, I would use rSpec or Test::Unit
• STRONGLY suggest not to use instance variables
  
• If you start to write any code that interacts with an object other than your model, something is wrong with your model, don't try to fix it with shitty tests

Controller tests:

• In rails, I would use rSpec
• rSpec Storyrunner is nice, but *I* think it's a completely different realm for those that haven't been used to writing tests for very long
• Try not to hit the database if you can
• When dealing with tests that MUST hit the database or SOLR or Sphinx or (OLAP Cubes for those in a Enterprise-y environment) outside of the application code, categorize them somehow to separate them from the faster running tests so you can run them at night or every hour while running your main test suite in seconds

View tests:

• I hate view tests
• But I do them with rSpec

association.is_working_properly?

When working with a team on a project things can get quickly out of sync. However, when working with a geographically seperated team, things can get out of sync before it even happens -- quick. With source control and high level languages of today, being disorganized amongst team members is much better than it was a few years ago, but still still happens just as much.

Things can go wrong while working on a team like this and usually do, quickly like I stated previously. One area they can go wrong is with migrations. This is where an issue can pop up when creating an association between your domain models.

manufacturer = Manufacturer.new(:name => "Chevrolet")
manufacturer.models.build(:name => "Corvette")
manufacturer.models.build(:name => "S10")
manufacturer.save

In Rails, they're supposed to just work and most people can continue building their application without testing to make sure a "model" is associated (added to) a "manufacturer". The issue is if someone on your team blindly creates a migration and checks it in because they think they're a "guru" and don't need to test or run tests before checking-in. This is a major-fail. This problem happened in my current project and stopped development which pissed me off since my pair and I had to go back and fix someone else's mistakes when we should have been able to continue on with the features we needed to implement.

When creating an associated domain model there's usually some sort of change that needs to happen to the database. This interaction or creation of, is created by a human -- you or me.  It's in the form of a migration as well.  The human element introduces a point of failure so it must be tested, even if it's something minor like adding a column that is used by the framework.

The moral of this story is, test everything if a human has changed the state of it.