https://github.com/chloerei/code_campo

我写 Test::Unit，我觉得 Test::Unit 语法平实，更容易理解。楼主可以参考 code_campo 的 git log。

测试其实就一个逻辑：进行了什么操作，发生了什么效果。简单的测试很多时候很有效，不要把逻辑的复杂和测试的复杂绑定起来，写测试的时候把自己作为第 3 者观察就清晰很多了。

#10 楼 @ripple 放在 app/model 就可以全局都用。如果一定要在启动环节载入就放在 config/initializers。

#3 楼 @cqpx http://codecampo.com/topics/84 HTML5，让 Ajax 改变 URL 且支持后退

直接用这个类

#4 楼 @daqing 模拟用户行为的不是 cucumber，是 webrat 或 capybara

注册是 devise 提供的，一不小心忽略了

#56 楼 @huacnlee 强制白名单之后，不设置就写不进，程序员就不会忘了。

#50 楼 @hisea 想了一下，是指 permission 可以指定 model attr accessible 的情形？

类似这种情况？

topic.update_attributes params[:topic].slice(current_user.role.permission[:topic])

那确实写在 controller 和 model 分别不大了。不过我觉得实际应用权限也不需要太灵活，公司网站（一个论坛）实现一个分门别类的权限控制，实际上开发、运营和审核也就几个人而已，用上的权限也就分 3、4 个够了。

#11 楼 @Rei 奥，发现百分号被滤掉了……

http://movie.douban.com/tag/%E7%BE%8E%E5%9B%BD

#8 楼 @tualatrix 有效 URL 里面的中文应该要转义的，chrome 能显示中文是浏览器端的处理，复制出来还是会变成转义字符。比如

http://movie.douban.com/tag/%E7%BE%8E%E5%9B%BD

#50 楼 @hisea 实现各种逻辑，写在 Controller 和 Model 复杂度都是一样的。我只是赞同写在 model 里而已。

#14 楼 @hhuai 程序员自己的测试是白盒测试，要灵活。外部需求提供的需求是黑盒，就只定义粗粒度的测试。

我没接触过外包，看你描述是外部接口都定义好了，那就是外部测试了。TDD 主要是讲程序员自己的测试，可以灵活迭代，多写内部测试还是有助于更快达到外部测试的需求。

#11 楼 @evan 测试是用来检测代码实现是否和想法相符，想法可能是错的，测试也可能是错的，但比什么都没有好。

#9 楼 @hhuai

当脑中有一个大概的设计，觉得应该有一个接口，输出输出是这样子，把这个想法用代码表示出来，这就是一个测试用例了。

然后觉得这个接口太大，需要一些小的处理方法，也把这个方法的输入输出地用代码表示，就是另一个测试用例了。测试用例可以随着想法变更增删。

其实打开终端，敲调试代码的时候，就是在写一次性的测试代码，而且很可惜的是这些代码只用一次就扔了，其实很可能还有用的。

以前学习 Qt 编程，未接触自动测试，也是用了 Rails 才用上了。现在我对前端测试不熟，但也觉得是必须的，像 jQuery 本身是带测试的。前端测试要怎么整理我实践还太少。

我不追求完全覆盖，只要求关键覆盖。

觉得写测试时间太长的原因一是不熟练，二是没有把调试时间一起考虑。

维护别人的项目时候我才会后写测试，自己写都是先写测试。

#43 楼 @hisea attr_accessible 有 role

这两个我都觉得不是好的选择……

我这明天如果没任务也去搞~

我觉得白名单写进 Model 好，不然控制器还得知道 Model 的属性。用了 attr_accessible 之后，控制器知道 role 就行了，相当于打包属性组。

#6 楼 @camel V2EX 也是有这个提醒的，发帖量大就有用了。

Master 默认白名单了

https://github.com/rails/rails/commit/641a4f62405cc2765424320932902ed8076b5d38

#15 楼 @zipme #17 楼 @hooopo

确实有漏洞，现在补上了。大家一定要用 attr_accessible 阿。

#7 楼 @iwinux 用白名单而不要用黑名单

#10 楼 @race 我是这样跑的

ruyb -I. terminal_test.rb

#2 楼 @Azon execjs 还需要后端才能处理，想简单解决可以加上这个 Gem

gem 'therubyracer'

为什么要手工管理软件呢

我觉得有 end 挺好，用 snippets 不用手敲，每次看见 end 会让自己有种安定感，就像开辟一个工作区一样

class Terminal
  # Example:
  # Terminal.set_pricings({
  #   "A" => {1 => 2.0, 4 => 7.0},
  #   "B" => {1 => 12.0},
  #   "C" => {1 => 1.25, 6 => 6.0},
  #   "D" => {1 => 0.15}
  # })
  def self.set_pricings(pricings)
    @pricings = pricings
  end

  def self.pricings
    @pricings
  end

  def initialize
    @products = {}
  end

  def scan(name)
    @products[name] = @products[name].to_i + 1
  end

  def total
    result = 0
    @products.each do |name, number|
      result += self.class.item_cost(name, number)
    end
    result
  end

  def self.item_cost(name, number)
    pricings[name].keys.sort.reverse.inject(0) do |sum, package|
      if number / package > 0
        sum += ((number / package) * pricings[name][package])
        number = number % package
      end
      sum
    end
  end
end

require 'test/unit'
require 'terminal'

class TerminalTest < Test::Unit::TestCase
  def setup
    Terminal.set_pricings({
      "A" => {1 => 2.0, 4 => 7.0},
      "B" => {1 => 12.0},
      "C" => {1 => 1.25, 6 => 6.0},
      "D" => {1 => 0.15}
    })
  end

  def test_should_get_cost
    terminal = Terminal.new
    terminal.scan 'A'
    assert_equal 2.0, terminal.total
    terminal.scan 'A'
    assert_equal 4.0, terminal.total
    2.times{ terminal.scan 'A' }
    assert_equal 7.0, terminal.total
  end

  def test_multi_item_cost
    assert_mult_scan_cost_equal 32.40, 'ABCDABAA'
    assert_mult_scan_cost_equal 7.25, 'CCCCCCC'
    assert_mult_scan_cost_equal 15.40, 'ABCD'
  end

  def assert_mult_scan_cost_equal(expected, names)
    terminal = Terminal.new
    names.each_char do |name|
      terminal.scan name
    end
    assert_equal expected, terminal.total
  end
end

eval 得不必要，Hash 就能解决

在我看来 @fsword 的言论没有问题。楼主专门发个道歉贴但同时想封别人的嘴真的有意识到问题吗？