sunaot

require 'minitest/autorun'

class ModuleTest < Minitest::Test
  def test_module_eval
    debugger = Object.new
    debugger.class.module_eval do
      define_method(:debug) {|s| %(debug: #{s}) }
    end
    assert_equal 'debug: Hello', debugger.debug("Hello")
  end

sunaot

module EnumHashSelector
  DEFAULT_RESOLVER = ->(model_class, method_name, key) {
    "activerecord.enums.#{model_class.name.underscore}.#{method_name.to_s}.#{key}"
  }

  def self.i18n_path_resolver=(resolver = DEFAULT_RESOLVER)
    resolver.call(model_class, method_name, key)
  end
  
  def enum_selector(model_class, method_name)

sunaot

Subversion を Git へ移行したい (そして共有方法として GitHub を使いたい) 場合に考える観点をあげてみます。

人

• チームに Git にくわしい人がいるか？　いない場合、聞く先があるか？
  • チャットに git ルームをつくるなど
• 習熟度に不安があったら、やってはいけないことリストとこうすべきリストの整備が初期の混乱を防ぎます
  • force push 禁止
• ブランチはリモート追跡ブランチからきる

sunaot

問い

permits ってなに？

class FoodsController < ApplicationController
  permits :name, :amonut
  
  ...
end

sunaot

ユニットテストでテストを書くか書かないかの判断の話

お題

メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか

テストとは

まず、基本の考えとしてなぜテストをするのか？というのがあります。

sunaot

git pull の動作

pull は引数なしが推奨です。 pull は誤った (意図しない) リモートリポジトリやブランチを指定したときも動いて、そのリポジトリのリモートブランチから展開されているワークツリーへのマージとして働きます。一方、引数省略するとリモート追跡ブランチから自動的に pull 対象を決定します。こちらのほうが一般的に事故は少ないです。

git push の動作

こちらは git のバージョンしだいで推奨が変わって、次のようにわかれます。

sunaot

  private

  def fixup(data)
    return nil if ! data
    return_data = output.isatty ? data : data.gsub(/\cM/,"")
    if return_data.respond_to?(:force_encoding)
      return_data.force_encoding('utf-8') if return_data.respond_to?(:force_encoding)
    end
    if running_on_windows?
      begin

sunaot

今後何度も書くことになるだろうから repo へコミットする .gitignore の使い方について書いておく。まあ、ゆるーく使って余分に ignore 書きまくってもいいんですが覚えておくと、はかどります。なお、man に書いているというつっこみを受けた。

以下の方針で運用すると扱いやすくなります。

• プロジェクトで使う .gitignore ファイルへはプロジェクト固有でバージョン管理から外したいものを書く
  • 例： そのプロジェクトでできる中間成果物、スナップショットで残したいだけでバージョン管理する必要のない成果物 (テスト結果とか) など
• プロジェクト固有ではなく発生し、バージョン管理から外したいものはグローバルな gitignore ファイルへ書いておく
  • ~/.config/git/ignore
  • 例： OS が勝手につくるファイルやフォルダ、エディタの作るバックアップファイルなど
  • 自分で育てなくてもグローバルな gitignore のための雛形があるので自分が関わるものを追記していけば OK.

sunaot

ユニットテストのガイドライン

• 一つのテストに一つのアサーション (論理的なアサーション)。
  • 一つのテストで確認する意図は一つにすること。
  • アサーションの機能が弱いために、一つのことを確認するためにいくつかの実装上のアサーション (物理的なアサーション) を書かざるをえないケースはありえる。
• よいユニットテストは一瞬で実行を終えなければならない (そうじゃないとコードの変更のたびに実行するのが面倒になる)。
• 書くべきテストとは、同値分割と境界値分析を考慮して、モジュールの外面的な振舞いを検証するテストで、エラーを見つけられそうなもの。
  • 「テストとは、エラーを見つけようとしながら、プログラムを実行する過程である。」
  • 「良いテスト・ケースとは、まだ発見されていないエラーを検出する確率の高いものである。」
• ホワイトボックスでの同値分割と境界値分析によって導かれるすべてのケースを網羅すること、ではないのがポイント。それによって外面的な振舞いに影響を与えるものが基本的な検証すべきケース。

sunaot

The principles of OOD

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

日本語での紹介

http://qiita.com/kenjihiranabe/items/9eddc70e279861992274

Open-Closed Principle についての解説日本語訳