This question already has answers here:
How to get started on TDD with Ruby on Rails? [closed]
(7 answers)
Closed 6 years ago.
I currently work in a big Rails App that sadly has no test coverage and is currently on version 3 of Rails.
What would be the best approach in order to migrate to Rails 4 ? I know it's better to migrate step by step on Rails version, but the application is very big.
Should I invest in Tests before doing so ? What kind of tests ? Unit testing ? Integration tests ?
Our approach looked like this (and religiously followed this guide):
Make sure we have unit tests for all models/controllers
Add integration tests for all business critical paths in the app
Add the strong_params gem to the app, see what breaks, fix the broken things
In Gemfile, for each gem with version, look at gem dependencies and attempt to upgrade to latest version possible (i.e., removing warnings, update integrations, making sure tests pass)
Upgrade the rails gem -- see what breaks, fix the broken things
You'll notice that in the guide, the first thing they drill on is test coverage. It sounds like that might be the best place for you to start.
I am suggesting you to have atleast rspec unit test for all models and controllers then proceed to upgrade the application.
But without tests if you upgrade then it would be a problem to find any issues inside the application, becuse we cant predict whether it's due to upgrade or issue with the written code.
If you have very complicated views like calculations or showing some important informations then it's good to write integration test as well, else that's not a necessary.
Related
I'm a PHP dev mostly and just starting out with Ruby, so please correct me if I say something dumb.
I'm working on fixing some bugs in a "legacy" app written in rails. The app itself has never been unit-tested. I can see the test scaffolding generated by rails but tests are nowhere to be found.
The app is pretty big and the code quality is very bad, so I wanted to write some units tests for the functionality I'll be fixing, before writing any code.
The problem is that when I run rake test command, the testing DB is created, but if I write any tests it keeps crashing on me. There are several problems with some relations and keys which I tried to fix, but more problems just keep appearing. I do understand that the DB is created with schema.rb file, but I'm sure it is just outdated by now. It is another issue I will maybe fix, but for now I just want to write some basic unit tests not even using the DB itself.
So the question is: is it possible to write just unit tests for some methods without invoking all the test DB scripts? I'm aware that this is maybe not the best practice, but I will feel better modifying the app with some test coverage and starting with fixing the DB I do not yet understand seems like a bad idea to me.
I'm using Ruby version 2.1.10 and the app is written in Rails 4.0.4 - these seem to be the latest versions I managed to run the app on.
I have an existing Rails app that I built using Rails 3, Mongoid/Mongodb and Devise. The app is running fine. I'd now like to add some tests to it (sure, shoulda done this in the beginning but the learning curve for just Rails was enough...).
I've used several pages to get it going, especially the Rails guide and this blog post about Mongo and Cucumber/Rspec. My concern here is that between all of the "add this to this and such file" that I've done to try and get this working (and it's not) I've made such a mess of things that it might be better to start over from scratch. With the testing portion of the app.
I thought I would just delete the spec and test directories and re-gen the tests but I can't find a command to do that (the regen).
I've built a very simple test (assert true) but I'm getting:
D:/Dev/TheApp/test/test_helper.rb:10:in `<class:TestCase>':
undefined method `fixtures' for ActiveSupport::TestCase:Class (NoMethodError)
I think the real issue here is that I'm using MongoDb and the test architecture in Rails seems to really really want to do ActiveRecord. Not sure if those two are compatible.
Is there a quick way to build a barebones test directory? My short term solution is to just roll back those directories. Hoping for a better solution.
The blank tests are really worthless. If you didn't have tests/specs of value, then just start from scratch. And if you want to start over, you should just delete them and start new.
You could treat your code as "legacy code" as defined by Michael Feathers in Working Effectively with Legacy Code -- that is, code without tests.
Take a look at this getting started with rails testing guide over at 10gen:
http://www.mongodb.org/display/DOCS/Rails+-+Getting+Started#Rails-GettingStarted-Testing
is it worth the change from Rails 2 to 3 if im starting to work on a new application? are all the plug-ins and gems available for 2 now available for 3 as well? im used to developing and learning on Rails 2 and I'm afraid of switching over.
Thank You
You can check if the plugins you use work with Rails 3 here. Personally I'd say, if all the plugins that you use work with Rails 3 then you should upgrade, there are some nice changes in Rails 3 that are worth using.
I just started a Rails project a few weeks ago with Rails 3, and I've been quite happy so far.
Some gems/plugins don't quite work yet. For example, Selenium and friends seem to be a little behind, though after trying a few plugins I finally got it working fine through Capybara. In_place_editing isn't working out-of-the-box for me (I suspect because of Rails 3), though there are alternatives and it's not complex at all. And I had some trouble with factory_girl, though apparently there is a version for Rails 3 now.
But in general, most plugins I've tried seem to be working fine at this point. Maarons has already pointed you at RailsPlugins.org if you want to check for a specific plugin.
Finally, there are bunch of things that are just better in Rails 3 (see the release notes). I used Rails 2 for a smaller project a while back, and using Rails 3 now, I was pleasantly surprised by the new routing (much less confusing), and the added bundler support (makes deploying much less scary).
Since you're setting up a new project, I'll also mention that I've been quite happy with Ruby 1.9.2 (as opposed to 1.8.7). Check PragDave's blog post for some major changes. The only thing that I recall needing explicit tinkering was the debugger -- just use the ruby-debug19 gem and you'll be fine.
Fear isn't a good enough reason not to switch.
There are quite a few plugins that only work on Rails 3, so I'd recommend starting a new project with 3, if you're starting now.
I would expect this question the other way around :)
If you are starting a new application then I'd say always try to go for the latest stable versions unless there is some really good reason not too.
Not only does it save you the trouble of migrating at a later stage (which in a likely hood will happen sooner or later), but you get to improve on a personal level as well by learning something new. And the later is something I find very important. If it's not challenging, it's not fun, and if it's not fun, then it's not gonna be good (for me at least).
As for all plug-ins and gems being available, probably not but the ones that are still being develped and improved will be if they are not already.
You will have to switch eventually, so this is a good time. Why waste time on something you will have to change sooner or later? Rails ecosystem is quite responsive, and most plugins and gems are already 3.x compatible. Many have even deprecated 2.x support.
We've recently upgraded our Rails application.
To be extra sure everything works, I've tried to get the tests and specs of the various used plugins (26 at current count) to work, thinking then to add those to our continuous integration, which only runs the main application's specs.
I've run into a lot of problems even getting the specs/tests to run at all, not even getting to any individual test failures. For example, I've run across this problem: http://rails_security.lighthouseapp.com/projects/15332/tickets/7-rake-spec-plugin-fails-on-rails-2-1 (thanks by the way for that ticket, even though the issue wasn't fixed).
So the question is: Are we unusual in that we've ever cared about running plugin tests ? It doesn't seem to feature much here on SO. My nagging feeling is that they should be run as much as the main specs, but you could also argue that since the main specs work, the plugins must also work.
Alot of it depends on the plugin/gem being used.
If I know the author/community of the gem is competant I will skip the tests and simply use the latest stable release and freeze that gem. I will then track the progress of the development using github.
If the plugin/gem is written by an unknown party I will run the tests and freeze the gem/plugin and again monitor the development.
Sometimes however I will write my own contributions to the gem and fork the code. I will clone the repo in github and base my installations from that. At which point any and all changes result in a complete test run.
With all things in the open source world there is an element of trust between the creator and the users of those pieces of code. The tests themselves don't tell me much about the codebase, it shows there are tests and thats it. Do they test everything ? Are there edge cases ? . Its this element of trust I have with certain developers in the community that means I forgo worrying over running tests for those gems.
Its a slippery slope testing everything, where does it stop ? Would you test rails every release ? No, you assume the community has done this for you already.
I'm developing an application with Ruby on Rails that I want to maintain for at least a few years, so I'm concerned about the next version coming up soon.
Going from Rails 1 to Rails 2 was such a big pain that I didn't bother and froze my gems and let the application die, alone, in the dark.
On this project I don't want to do that. First because this new version looks awesome, but also because this application may turn into a real product.
How can I prepare my application so that it will be upgradable with as little changes as possible.
How time consuming do you think switching version will be?
And what about my server? Deployment?
I'm already looking at deprecation notices... what else can I do?
The best thing you could do would be to follow development of Rails 3 via blogs and the Github repository and keep up a copy of your app along with it.
The official Ruby on Rails blog is updated with "What's new in Edge" posts every once in awhile. There are other blogs that often write about new things in edge as well. Larger features are often highlighted in these blogs, so you know about all the cool new features you can play with.
I'm not sure how close Rails 3 is to release (last I heard the core team was talking about a release at RailsConf 2009 in May), but you can always freeze the edge version of Rails into your application and just see what breaks. If you are using git, or another DVCS, you might make a branch specifically for Rails 3 and periodically update Rails to the latest edge code. Just be aware that edge Rails is a moving target so things in your app may break or fix themselves as you are pulling in newer Rails code.
Update:
Jeremy McAnally has a ton of info on upgrading from Rails 2 to Rails 3 on his blog.
http://omgbloglol.com/
I don't think there is going to be a major problem. Going off what was said in that initial report the Rails team realized that they can't do a major rewrite like they did from 1 to 2.
They even say:
I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3.
I would be more concerned going from Merb to Rails 3.
The single most important thing you can do to make it easy to migrate to a new version of rails is to have a comprehensive test suite. Without a good test suite, I would never have the confidence that the new version of rails hasn't broken something in my app. On the current Rails app I'm working on, we started on Rails 2.1.1 back in October of 2008. Since then, we've migrated to Rails 2.1.2, 2.2.2, 2.3.2, 2.3.3 and now 2.3.4. I did the migrations to 2.3.2, 2.3.3 and 2.3.4...and for the 2.3.2 and 2.3.3 upgrades, we had some failing tests that alerted us to problems we would not have discovered without having such a good test suite. The failing tests actually alerted us to a regressive bug in rails that there was a patch for on the Rails lighthouse but that was not included in the release (since it was discovered, right after the release).
Once you've got that test suite in place, just stay current with each rails release (waiting a couple weeks to upgrade is fine, just don't skip any of the releases).
Yehuda Katz (a member of the Rails core team) has stated that there will most likely be a transitional release, containing deprecation warnings and such.
So as long as you have a good test suite to expose the inevitable upgrade problems, and stay current with the Rails release, the migration to Rails 3 should not be too difficult.
As simple as:
One
Two
Three
Great screencasts from Ryan Bates.
For preparing your application, the best way it what Jared said. Follow the Rails3 development.
For the time consuming, I think it depends of how you've followed the rails3 development before it's release.
And for the deployment, it shouldn't take too much problems. Rails 3 will be using Rack. So you can start it with mongrel, passenger or any server/gateway it shouldn't give you any problem.
There are some major changes in Rails 3, I posted about my experience upgrading my app to Rails 3 here: http://rails3.community-tracker.com/permalinks/5/notes-from-the-field-upgrading-to-rails-3
A good start in preparing would be to migrate over to using bundler. And doing a very deep review of strings that will go through the new XSS protection scheme.
There are going to be some automated compatibility checkers. Also, keep an eye on http://www.railsplugins.org/ so that you know if the libraries you depend on are going to be upgraded. The Rails Core team seems to be giving a lot of advance notice to the community this time around, so any lib that is actively maintained should be good to go.
Just do one thing
take a backup of your old version project first and then
on terminal(command prompt) write
rails new path/of/the/project
for example if my 2.3.* project is at home/rails_projects/myproject then
rails new home/rails_projects/myproject
or
cd home/rails_projects
rails new myproject
It will ask if there is any modifications done in any /config or other files. Do appropriate.