I have been working with Cucumber lately and have been retrofitting one of my main projects Sumuv.com with appropriate behavioral tests. We have a fully functional test suite written with Shoulda and Test::Unit, so I am not particularly interested in translating the unit and functional tests to RSpec.
This is the vegetable you are looking for.
I figured that since the Cucumber BDD tests are completely different than the Shoulda unit and functional tests, I could just slip my Cucumber steps right on in. It does seem a little strange to be writing the functional tests in Test::Unit and the behavioral steps in RSpec. In the future I will probably follow the Shoulda train and move to RSpec exclusively, but I am enjoying the differences in the two platforms on this particular retrofit.
While I am mentioning the Shoulda train, I really enjoyed Thoughtbot’s post “This should_change Your Mind“. Their very simple explanations of the difference between behavioral testing and functional testing created a clear distinction in my mind. It was the golden nugget of wisdom I had been looking for.
I have been a big fan of Binary Logic’sAuthlogic gem for handling site authentication and user sessions. I love the clean interface and versatility. A lot of forethought went in to make this an elegant interface on top of some pretty robust and secure code.
As a result of this work, I have created a set of Authlogic behavior steps to use in my Cucumber tests. These steps cover most of your basic functionality and provide some helper functions that you can use in your other step definitions. The Cucumber feature definitions cover the major elements of authentication: logging in, logging out and the presence of a UserSession.
I will continue to improve the quality and coverage of these features. I plan to include a set of features to cover user registration. I offer this here because I find it useful for my other projects. If you find it helpful too, please let me know!
This information is readily available from Github after you create a new repository, but I have been bouncing around a lot of different computers lately, so I needed a refresher course. Running these statements at the command line will set the global Username and Email for all of your repositories.
git config --global user.name "Jay Sanders"
git config --global user.email my-cool-email@spam.com
Can I get suggestions on how to move my app from GitHub to Heroku and back?
You can do this if you’re using git locally. The magic of
decentralized revision control makes it possible, since every checkout
is a full repository in its own right. What I suggest is adding two
different remotes to your local checkout, and then you can push to
both. Something like this:
git remote add github [EMAIL PROTECTED]:myaccount/myapp.git
git remote add heroku [EMAIL PROTECTED]:myapp.git
Then you can do “git push heroku” and “git push github”, or pull, or
diff, or whatever. You could also name one origin, which will make it
the default, but it would probably lead to less confusion if you had
to explicitly name where you wanted to push or pull from each time.
In my specific case, I am already hosting my codebase on Github. I want to keep the main repository there because I like all of the available features. I also want to be able to work with collaborators and allow them to make commits to the master Github repository.
Heroku is amazing, but when you push to the Heroku repository it automatically restarts the application. Using these methods, I can maintain a situation where one person is able to manage what actually goes “live” to Heroku, while everyone else can work away on Github using the normal collaboration procedures.
MacPorts is a fantastic resource for installing and managing libraries on OSX. When working with Ruby on Rails, I installed MySQL (and Postgresql) using MacPorts, but had trouble getting the MySQL gem to install and connect. The error message I received was:
Here is the magic formula:
sudo gem install -v 2.7 --no-rdoc --no-ri mysql --
--with-mysql-dir=/opt/local/lib/mysql5
--with-mysql-config=/opt/local/lib/mysql5/bin/mysql_config;
I have been using AASM as my default State Machine Rails plugin for quite some time. It has always worked great, but now there is a better, more thorough State Machine I recommend. state_machine 0.9 has just been released, and as you can read in this blog post, they are rapidly moving towards the finalization of the 1.0 version. http://www.pluginaweek.org/2010/04/19/state_machine-0-9-0-locked-and-loaded!
What lead me to discover this fantastic plugin was the need to be able to call ActiveRecord observers in relation to the State of an object. With AASM, I had to incorporate my lib class calls in a method that was referenced in a state definition. I didn’t like this because it required my Model to have too much knowledge of the outside world. I think it is a best practice to encapsulate this type of functionality into an observer, leaving the model to be happy in it’s own little world. state_machine accomplishes this by allowing the placement of observer calls using a DSL provided by the plugin.
I am making the transition from attachment_fu to paperclip on a very large project of mine. I wrote the following method, inside of my old attachment_fu model ItemImage to do the work. I wrote it to run from inside the rails console. It gives handy messages out letting you know what happened.
I’m using Sphinx and Ultrasphinx for the search engine on one of my projects. I have been struggling with ways to automated the indexing of the database as the commands are rake commands on the command line. Turns out that rufus-scheduler is an excellent solution to this issue. If you allow the scheduler access to the rake file, it is as simple as this schedule below – it is designed to reindex every 90 minutes. I have chose to use the ultrasphinx:bootstrap command because it also has the God like quality of making sure the search server is running at all times.
