i = 10
5.times do |i|
end
iComputers do not know what "modifyPlace" means or what data might be a good value for "latitude".
Object.fixture? At least the responsibility then remains with the model object itself, close to the declaration of its validations. And the controller tests stay uncluttered. You can change properties on that single instance in your test itself, if that particular value is what you are testing. This way, the controller tests do not break. And if you add validations, changes only need to be made in one other method.<b> tags.<drag> tag and a <drop> tag. Each <drag> tag attribute can specify which mime formats it will export to (i.e. application/pdf, text/plain) and a callback function for fetching the data each format. A <drop> tag event handler can choose an available format when a drop is made and update its appearance.irb(main):001:0> class << :aBut.. but.. but.. I thought adding instance-specific methods was a hallmark of Ruby metaprogramming?
irb(main):002:1> def foo; "bar"; end
irb(main):003:1> end
TypeError: no virtual class for Symbol
from (irb):1
String and Fixnum for two. I'm guessing that this is true of any objects that are accessible as literals.def voyages_of_sinbad; 4 + 3; end, that would have to return not just the result of computation, but then look up the possible virtual class. Whether or not a virtual class for 7 had been created, it would have to at least check. So this look up would be a requirement of any numerical computation.7.secret_info to pass messages between objects!)Go on, try it. I dare you. I double-dare you:
class UserController < ActionController::Base
def send
end
def request
end
def render
end
end
These are all natural enough names for controller methods, but your controller will mysteriously vanish, cease to operate in strange, strange ways if you use any of them.
Why? Because you are overriding methods crucial to the internals of the controller. In the first method, Ruby's Object#send. In the next two, ActionController methods.
How to save yourself time: I really hate silent failure or mysterious failure. But you can make the silent failures clear and noisy (oxymoronic, I know!). Try something like this:
module ActionController
class Base
def Base.method_added(sub)
raise "Cannot override action 'send'" if sub == :send
raise "Cannot override action 'request'" if sub == :request
raise "Cannot override action 'response'" if sub == :response
raise "Cannot override action 'render'" if sub == :render
#...
end
end
end
Ruby head-scratching magic:
irb(main):001:0> if falseBut now:
irb(main):002:1> x = true
irb(main):003:1> end
=> nil
irb(main):004:0> x
=> nil
irb(main):005:0> y
NameError: undefined local variable or method `y' for main:Object
from (irb):5
irb(main):006:0>
This here is very unusual, and I'm not sure if it is part of the Ruby specification or just the implementation. From what I gather, the declaration of 'x' is a side effect of the parsing of the conditional block. What other side effects to unexecuted code are there that we should know about?
The oddity does not carry over to the right side of assignment:
irb(main):001:0> if false
irb(main):002:1> x = y
irb(main):003:1> end
=> nil
irb(main):004:0> x
=> nil
irb(main):005:0> y
NameError: undefined local variable or method `y' for main:Object
from (irb):5
irb(main):006:0>
Why is the specification/implementation question important?
Because if we could rely on this behavior we could write more compact code, writing fewer variable declarations. For example:
if some_condition
x = true
end
#..
do_something if x
rather than:
x = nil
if some_condition
x = true
end
#..
do_something if x
if we can count on this in future and all implementations of Ruby.
def test_signupI want to create required dependencies automatically:
user = User.sample
post :signup, { :user => user.attributes}
assert_equal 1, User.count
end
def test_signup_creates_accountI want attributes to be overridable:
user = User.sample
post :signup, { :user => user.attributes}
assert_equal 1, Account.count
end
def test_signup_requires_emailI want even nested attributes to be overridable:
user = User.sample(:email => nil)
post :signup, { :user => user.attributes}
assert_equal 0, User.count
end
def test_signup_creates_accountAnd I want to make minimal changes (none if possible) to my model classes to support this stuff.
user = User.sample(:account => { :balance => 5.0 })
post :signup, { :user => user.attributes}
assert_equal 5.0, Account.find(1).balance
end
