render :action => ‘details’ will render the details.html.erb template and or action details (the def doesn’t need to exist, only the template).
render :template => ‘details’ fails. It doesn’t run relative to the controller, so you have to run: render :template => ‘/controller_view_path/details’ for it to work.
In the end, the result is the same.
I’m sure many of you have mixed feelings about testing, and get shivers on the spine when someone mentions TDD/BDD.
Well, I’m a big adept of testing, specially TDD and its newest child, BDD.
Unit testing in general is a tricky skill to learn, and requires a lot of motivation and faith on what you are doing. I have started in the world of Unit Testing about 4 years ago, and TDD/BDD ~3 years ago and the more I learn, the more I see it’s actually an art.
I used to defend BDD religiously, and I was one of them, heck, I even looked a testless application from behind the lens of prejudice, for me, it was basically crap.
Of course, that’s how our mind works. We see the world as we are, and I was over-reacting, basing my judgement on some internalized archetyped beliefs:
* Code without tests is crap
* Rails code must be tested, if you don’t test you are a worthless and doesn’t deserve to live
* BDD is the new tendency, everyone should be using it
* Outside-in! Outside-in! Or die!
Now, don’t take me wrong. Unit-testing, TDD and BDD are very valuable disciplines, but the message is being given in the wrong way, in my opinion.
I still love BDD. Cucumber for me is one of the most well-developed pieces of software, it’s really amazing. rSpec makes unit-testing fun and clear.
Critical features should be always unit-tested, following TDD/BDD or not. However, there’s a culture out there that makes you believe you should test every freakin’ aspect and artifact of you application.
That’s insane. That’s overuse of testing. That definetly doesn’t relate to the pragmatic/agile way in my opinion.
Take Selenium, for example. Cucumber+Selenium is a killer combo, in both senses. It works nicely and you can test JS and Ajax features, but it is just too slow. Every time you launch it, it takes up to 10 seconds to launch on a modern computer, sum that with Cucumber’s startup time, and every time you want to go through it, you loose around 15 seconds.
Every successful application I have worked on have started with little or no unit-testing, and once the money started flowing, we had the time and resources to build a better testing infra-structure. That’s a point agains BDD, unfortunately. As magic as it sounds, the real-world calls, and you are forced to code for food when you are starting.
So, I think it depends on:
* Resources: Microsoft can do BDD from the beginning 
* Time: Tight dealines calls for essential things only
* Skills: If you can sing BDD in 5 languages, then maybe you can BDD
for every programming artifact you create
* Environment: The company you work for might already have a very deep testing culture that it end up being simpler do follow TDD/BDD or unit-test your stuff, however, you can still overdo it.
* Patience: Come on. Selenium is just too slow.
So, whenever I am on my pragmatic mode (I still fall to my perfectionist side sometimes) I just have one rule: Getting Things Done and well. If for that I need to test something to make sure it will work as I expect, then so be it. If I judge it might go without tests, then, so be it, too. In the end, I’m giving priority to the most important resource we all have: Time.
My life just got a little bit easier.
As you might already have noted, I’m adept of simpe solutions and openness. I like having control of my stuff and tailoring things to work for me, the way I want, and improve gradually. That’s why I fell in love with org-mode and have been using it for the last 2 years, as my only and one personal information manager.
I’m also a GTD practicioner. Org-mode is the perfect platform for GTD because it just lets you implement the model the way you’d like. I just got the collect and review phase a tad easier, by getting Mail.app flagged mails imported directly into my inbox.org file.
This might seem like a mundane thing, but given the amount of support emails and often important stuff I receive through my work’s email, it just saved me the work of copying the text and collecting it manually into the inbox. I can now just flag it and trust that whenever I review my stuff, the data will be there, in front of my eyes.
So how to do that? Considering you already have org-mode up and running, you should first add the module org-mac-mail to the list of modules for org to load at startup:
M-x customize-variable
org-modules
Search for “mac-message”, tick it and save the buffer.
Then, just add it to your .emacs (or any of its dependencies):
(defun my-mail-import ()
(let ((org-mac-mail-account "OneLog.in"))
(org-mac-message-insert-flagged "inbox.org" "Flagged mail")))
(setq org-agenda-custom-commands
'(("F" "Import links to flagged mail" agenda ""
((org-agenda-mode-hook
(my-mail-import))))))
Eval the buffer or restart emacs. When you open the org Agenda, you should see a new option:
If you type
Isn’t that nice?
Let’s say you have a form, and this form has a credit-card select with the following options:
This would probably translate to the following in HTML:
<option value=”visa”>Visa</option>
<option value=”master”>Mastercard</option>
<option value=”american_express”>American Express</option>
Say you have a view test and you want to make sure this select renders the options as you expect. You could do the following:
card_type_options = options_for_select([['Visa','visa'],['Mastercard','master'],['American Express','american_express']])
form.should have_selector('select', :id => 'credit_card_type', :name => 'credit_card[type]') { |select| select.children.to_s.should == card_type_options }
I have tried using “select.should contain(card_type_options)”, but it would fail. The approach of converting the select’s chidlren to string and testing its equality to card_type_options works fine.
