DRYing Up YAML Fixtures (except for PostgreSQL!!!)

When creating YAML fixtures, there are many records that have many repeated values. For example:

user_1:
name: john
is_active: true

user_2:
name: billy
is_active: true

Here, the is_active field is repeated many times and has the same value true. This may be a default for many records. YAML allows you to set defaults:

defaults: &defaults
is_active: true

user_1:
name: john
<<: *defaults

user_2:
name: billy
<<: *defaults

Obviously, this simple example doesn't save us any time. However, if our defaults include many columns, this can save a lot of typing and headaches when default values need to be changed.

All this is wondeful... EXCEPT when your using PostgreSQL, and it's driving me NUTS!!! For some reason, this DRY method doesn't work. I haven't figured out why yet and my search for the answer has been rather futile. If any one has an answer, I'd like to know the reason.


W

assert*

For testing, we have a collection of assertion functions that come with RoR. They're fundamental to any testing infrastructure. Without them, I can't imagine how testing could be done.

However, on the site that hosts the API, I cannot find the functions available. They list the functions for ActionController, but not for general testing.

Hence, I did a simple search and came up with this lovely site. Enjoy!

assert* functions


W

Unit Test Runs All Methods

So I've been doing A LOT of testing recently, and it's starting to piss me off that I can't just run the method that I'm currently working on. It would be nice if I could, but I haven't been able to find out how to do it.

Currently, I'm solving this problem myself by adding flags to my setup method which will decide which methods to call. This is definitely a hack until I can find out how to do this properly... If I do find a solution, I'll be sure to let you know!


W

Testing

When developing anything, testing should always be at the forefront of your mind. After all, without testing, how are you supposed to know whether your application works or not? We certainly don't want our users to let us know about bugs. Hence, testing should always be a continuous task as you continue to build your application.

RoR provides a built-in testing environment for testing your application. So far, I've gone through testing our models. I will move onto controllers later. What I've seen so far is really nice! Firstly, RoR uses another database for testing. It does not touch your development database, nor your production database. By issuing the command:

>rake db:test:clone_structure

RoR will automatically clone the structure of your development database and create a new one according to your database configuration file. That's pretty neat. Next up, populating your database is easy as well. In RoR, there are things called fixtures which can be called before testing. These files populate your database with data that you need in order to run your test cases and are removed after testing.

For Unit Testing, all the models are available to you for testing. There are setup and teardown methods you can write that setup any pre-test things, such as creating files, and that remove anything post-test.

Testing is done in a usual manner using various assert methods. Errors and Failures are reported when running the tests.

One pretty neat thing is that RoR keeps statistics on your tests, such as code coverage. Simply type in:

>rake stats

and a table of statistics will appear. I will look into that a little more, but it should really helpful in determining whether or not the test cases are covering enough ground.

With RoR, it is very easy to design, code, and test in a continuous manner. Testing is so easy and integrated that it actually feels like its worth testing while I'm testing! That's rare!

W