2009/3/7 Phlip <phlip2...@gmail.com> > > > > In a recent upgrade I had to change > > the base class for my unit tests from Test::Unit::TestCase to > > ActionController::TestCase which I imagine would not have worked had I > > reverted. Are there not other cases of code that cannot be made to work > > in old and new version of rails? > > Why didn't you stay with Test::Unit::TestCase? The point of running the > tests > was to let them tell you what to upgrade. Because the test.rb file still > mutilates Test::Unit::TestCase directly, we did not need to change it until > after the Final Integration, when we stuck with the higher version number. >
I forget the exact issue now, but the test would not compile with Test::Unit::TestCase. Perhaps I could have changed the test code to make it work but changing the base class fixed it without changing the test. > > > Why does it matter whether the code runs in the old version of rails > anyway? > > So > all > tests > pass > when > you > integrate!!! An alternative strategy that has worked for us is to do the mods for the Rails upgrade on a branch. Merging in changes from the current master/trunk is then the equivalent of your integrate phase as it picks up mods done by other team members on the master. Only rarely does a test fail after the integrate as it requires that a change on the master is not compatible with the new Rails. The final release phase is then only the changes required by the upgrade and so is not a huge change, and it has been well tested along the way. In fact for a current project I am adopting a different strategy as an experiment. I have a branch which runs with edge rails. Occasionally I merge in changes from the current master and retest, then update to the latest edge and retest. This should ensure that at the next Rails release a minimal amount of work is required to release. I would take some issue with your comment earlier that you should only commit when tests pass fully. We use git where each user has a local repository, and there is a master repository which always contains fully tested code. Each developer runs a local branch on his repository and is encouraged to commit often. When he has completed a change and all tests run (typically two or three days work) then he picks up the latest mods from the master repository, retests and pushes his work to the master. He then starts a new local branch for the next phase. I am not suggesting that this is a 'better' way of working, but it works well for us. > > Otherwise you are integrating one huge change, without the ability to > safely > revert in small increments. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
