@beyondyuqifeng 你多虑了。测试又不是克隆，只要测到关键点就可以了。

@beyondyuqifeng 你比较的两个是不同的 object，又不是值，肯定是不能等价的。

另外，你这个测试没有什么意义，证明不了什么东西。

你可以，第一，测返回的是不是 Highchart 的 instance, 第二，返回的 instance 是不是有期望的值。

let(:chart){helper.get_highchart}

describe "foo bar" do
  expect(chart).to be_kind_of(Highchart)
  expect(chart.some_attribute).to eq(expected_value)
end

@beyondyuqifeng 他的那个问题提得就有问题，三个 expect 连在一起，肯定错的是第一个，后面的连执行机会都没有。

我不知道你具体比较什么，所以不好具体回答。

==好像是已经 deprecate。一般测值相等是用eq。你如果比较两个 object 值是否相等就应该用eq。测恒等是用be, 会比较 object id，一般情况很少用。

我觉得你可能测得太多了。有个 html 提交的打印页面就已经足够了。毕竟具体打印每个浏览器和操作系统都有区别的，没法也没有必要测。

楼主直接投 PR 啊

请贴问题代码。

我觉得打折的时候买比较合适。

道理是没错，问题是夸夸其谈的成本低，收益高，所以夸夸其谈的人多。

Window 下面添加 ssh key 不是那么直接的，需要借助工具，好像是 Putty 什么的。你要是玩玩，就琢磨一些怎么解决。你要有心学，第一步就什么都不要做，装一个 Ubuntu，玩转了再说。

不要着急部署什么的，一个rails server就可以看到效果了，非要到服务器干什么。部署还有很多相关的知识，你基础不牢就全是问题。有这个摸索的时间不如从基础学起。

常用的做法是，个人不能随意修改的东西比如密码、邮箱、用户名等等放一个表。因为修改时比较麻烦，需要认证、发邮件什么的。其他可以随意修改的比如自我介绍等等放另外一个表。

好处是 profile 的部分用户修改时比较方便，你也不需要加入特殊的逻辑。稍微麻烦的地方就是经常要 include，不过也不是什么大问题。

性能没什么好考虑的，你遇到了瓶颈再说。

@palytoxin 你只需要rails g migration MoveFooToBar, 然后修改，然后rake db:migrate就可以了。写其他的 rake 任务也可以，不过就和这个数据库的变化脱节了，得手动执行。

正常应该 ActiveRecord 就足够了。

类似这样

class MoveFooToBar < ActiveRecord::Migration
  def up
     create_table :bars do |t|
       t.blahblah
     end
     # 这个很重要！ 一定要reset
     Bar.reset_column_infomation
     # 然后该干嘛干嘛
     # 用create! 或者 save! 报错就可以回滚
     Foo.find_each do |foo|
       Bar.create! get_required_attributes_from_foo(foo)
     end
     # 然后最好先不要删除foos table
     # 等以后跑稳定了再加多一个migration就好了
  end

  def down
     drop_table :bars
  end
end   

只要是 ActiveRecord 或者 raw SQL 可以表达的就可以操作，当然一般来说也肯定是。

然后你把这个变动加到 migration 里面就行了。

前端 MVC 是另外一个世界，不是说不好，但那是一个 DHH 不喜欢的世界。

如果带你的人要你用 Windows，你稍微学一下就可以带他了。

用 Windows 那就是无限怪异坑。

无论什么框架都不存在什么集成的问题，一个是前端，一个是后端，分得很清楚。你稍微看一些那些 gem 的代码就知道了，Ruby 不过一两行，就是把 assets 放到合适的位置而已。

趁着年轻多做点实事吧，等老了有成就了再来卖价值观。

楼主辛苦了。

不要把这里当成盗版分享的基地好么。

我用 Figaro gem 管理 ENV。Rails 加载，读取方法和系统变量一样，但不进入系统环境变量。所以每个 app 是独立的。

你说的 dotenv 我不熟，看起来原理类似。

以上两种，不管哪个，肯定是要 ignore 的。部署时由 Capistrano 单独开任务上传到服务器，不通过常规代码的 push, 这个问题就解决了。这并非相互矛盾，因为服务器文件和你的本地文件可以假定是保密的，跟代码 repository 是两回事。

你即使 ignore database.yml 也可以用这个方法上传。

很快就会有了，七环都到河北了。

@ddyy 你和@blacktulip 一样都是肉测派的。其实这个场景写个测试挺简单的啊。

@michael_roshen 看了一下你修改的帖子，作者推荐的方法应该要好些。关于数据，你可以从服务器返回需要的数据啊，甚至直接加好 html 都可以的。

@ddyy, 有灵感可以记下来，不紧急的话分门别类实施。另外你如果实在喜欢生产数据，也可以写一个 rake 命令把服务器数据拉到本地，隔一段时间拉一次就行了。

要跑也是电脑跑，你可以同时干别的。

如果是紧急修改，再长时间也得部署。如果不是，你做事还得有规范，有计划，不能随意性太强。

这个只是个示范，没有让你一定用预读的 Array 啊。你可以读服务器返回的数据啊

$('input#search').on 'keyup', =>
  $.ajax
    url: 'foo/bar'
    data: $(@).val()
    success: (data) ->
      $(@).autocomplete
        source: data

@blacktulip 你说的具体情况具体分析没错的。什么时候测，测什么，什么成本最低又保证效率，确实是艺术，就连 DHH 也不敢说是艺术家。

@blacktulip 好吧，又发现一个人肉牛人。

@blacktulip Martin Fowler 写重构一书就强调测试是一切重构的基础。单从概念上来说，我不知你没有测试怎么样保证重构不出问题。