SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Unit Testing in Rails

    I've been reading Simply Rails 2 (thanks Sitepoint for having a PDF version!).

    I noticed that what it says is the default unit test for a model in story_test.rb is different from what I had. It said it would be something like:

    Code:
    require File.dirname(__FILE__) + '/../test_helper'
    
    class StoryTest < ActiveSupport::TestCase
      def test_for_truth
        assert true
      end
    end
    Mine's something more like:

    Code:
    require 'test_helper'
    
    class StoryTest < ActiveSupport::TestCase
      test "for truth" do
        assert true
      end
    end
    I'm assuming it's because Rails was version 2.0.x when the book was written, and now it's 2.2.x. But I wanted to make sure nothing else has changed.

    Everything the book says works, though I have changed all of the methods to the blocks instead, but I don't know if anything else is outdated.

  2. #2
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,269
    Mentioned
    196 Post(s)
    Tagged
    2 Thread(s)
    I have Rails vesion 2.1.0 and it generated a test file like
    Code Ruby:
    require 'test_helper'
     
    class StoryTest < ActiveSupport::TestCase
      # Replace this with your real tests.
      def test_truth
        assert true
      end
    end
    So the require changed with ver 2.1 and the test syntax in 2.2 ??

    I used to think Java was changing fast a few years back, but compared to Ruby it was at a snail's pace.

    As the book states
    Watch Your Version Numbers!
    It’s possible that by the time you read this, a more recent version of Ruby, SQLite, or one of the other packages mentioned here will have been released. Beware! Don’t just assume that because a package is newer, it can reliably be used for Rails development. While, in theory, every version should be compatible and these instructions should still apply, sometimes the latest is not the greatest.
    In fact, the Rails framework itself also has a reputation for experiencing large changes between releases, such as specific methods or attributes being deprecated. While every effort has been made to ensure the code in this book is future-proof, there’s no guarantee that changes included in future major releases of Rails won’t require this code to be modified in some way for it to work. Such is the fast-paced world of web development!
    .....
    Time Flies The version of Instant Rails used to test the code in this book was 2.0. As discussed earlier in the chapter, due to the fast-changing nature of the framework, I can’t guarantee that later versions will work.
    I'd say rather than install the same versions of the various components the book used, stick with what you have now and just remember if something looks different (eg. the migration file naming) or is broken, that it might be a versioning issue.

    If you enjoy getting into the nitty gritty details check out http://dev.rubyonrails.org/changeset/ and "Previous Changeset" to your heart's content.

  3. #3
    SitePoint Evangelist
    Join Date
    Feb 2006
    Location
    Worcs. UK
    Posts
    404
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the fast changing feast that is Rails would be much easier to live with if it was easier to determine exactly what changes occurred with each release. In my experience the changes are usually for the better, and in fact refactoring for many of the changes has improved my code. It just a shame it so difficult to track what going on.

    I'm looking forward to the merger with Merb that's scheduled for version 3 for example, but not the trawl through of logs for deprecation warnings that will be needed to find what needs refactoring ready for the upgrade.

  4. #4
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Change is fine, as long as they document it. I started using Rails, leaving the PHP Symfony framework, because they were making a lot of changes, but the documentation was so out of date that it was ridiculous. They had a new forms API, with little documentation on how to use it, for instance. They were switching to a new ORM, with little documentation on how to use that, and few plugins integrating it. And this was all between minor versions. Not to mention it was too complicated.

    I'm pretty happy with Rails from what I've seen so far, though. Hopefully I can keep up with the changes.

  5. #5
    SitePoint Evangelist
    Join Date
    Feb 2006
    Location
    Worcs. UK
    Posts
    404
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Generally, the documentation with Rails is very good. I use these two resources daily:

    http://api.rubyonrails.com/
    http://www.ruby-doc.org/core/

    It is just the revision information that is lacking in my opinion.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •