has_many :thoughts

Last night, I presented about RSpec to the Philly on Rails user group. It was a fun time. Seemed to go well; I hope people found it informative.

It was such a great idea to agree to present on it because a couple months ago I had barely used it. Agreeing to speak in front of a few people about it forced me to learn it. And, so far, I love RSpec!

Here are my slides.

I wanted to create XHTML ones but didn’t have time to learn how and just used Keynote. So they’re just big JPEGs. And they’re really not that useful unless you were there last night. I tended to use a lot of illustrations that won’t mean much unless someone is chatting along side them.

I will try and post up a few more posts about RSpec in the coming days to supplement the slides.

Since Colin came back from RailsConf raving about BDD, I’ve found myself priming up for what previously seemed inevitable. Behavioral testing as part of a new development process. Through a better testing structure I hope to..

1. better the quality of my code
2. refined organization of development time
3. focus on the task at hand
4. providing well covered documentation

With that said… and being the HUGE social loser I am… I’ve spent the last two days writing Specs and tests using RSpec 1.0. I have to say its almost too easy writing the actual tests, whereas the process of writing some tests, writing the code and making the code pass the test has been a definite shift in the way I develop. But not an unwelcomed one! ;)

Since RSpec seems to have a real lack of helpful documentation, I find myself wondering around their API, blog posts and best guesses. I have had great success so far, until I started writing some protected/private methods.

I had initially forseen a world of testing every single line and expression of code. Until I found this tidbit of info on the rspec mailing list…

1. Should you test protected and private methods in your specs?

No. You’re specifying the behavior of an object as seen by the outside world. Of course protected and private methods aren’t available to the world, so why would you need to test them? When you’re doing state-based testing, just call a method and then verify that it returns the expected value or leaves your object in an expected state.

This was backed up by almost every post after it. Seems that as a developer testing his code, I should stick with testing the main parts of the system that, overall, accomplish my task. Verifying that they are doing what I need them to do.

Private and protected methods typically back up other parts of the system that are public. For documentation purposes, I will probably write some tests that validate the functionality of a private/protected method IF they are made public. Just keeping them commented out to satisfy my entire spec.

Quoted RSpec mailing list post and another great post after that