Skip to content

Instantly share code, notes, and snippets.

Sunao Tanabe sunaot

Block or report user

Report or block sunaot

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@sunaot
sunaot / writing_unit_test.md
Last active May 13, 2019
テストを書くか書かないかの判断の話
View writing_unit_test.md

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

お題

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

テストとは

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

@sunaot
sunaot / git.md
Last active Nov 2, 2015
git push & git pull
View git.md

git pull の動作

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

git push の動作

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

@sunaot
sunaot / fixup_patch.rb
Created Aug 13, 2015
adhoc patch to ~/.heroku/client/lib/heroku/client/rendezvous.rb
View fixup_patch.rb
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
sunaot / git-ignore.md
Last active Nov 11, 2018
gitignore の使い方
View git-ignore.md

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

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

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

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

  • 一つのテストに一つのアサーション (論理的なアサーション)。
    • 一つのテストで確認する意図は一つにすること。
    • アサーションの機能が弱いために、一つのことを確認するためにいくつかの実装上のアサーション (物理的なアサーション) を書かざるをえないケースはありえる。
  • よいユニットテストは一瞬で実行を終えなければならない (そうじゃないとコードの変更のたびに実行するのが面倒になる)。
  • 書くべきテストとは、同値分割と境界値分析を考慮して、モジュールの外面的な振舞いを検証するテストで、エラーを見つけられそうなもの。
    • 「テストとは、エラーを見つけようとしながら、プログラムを実行する過程である。」
    • 「良いテスト・ケースとは、まだ発見されていないエラーを検出する確率の高いものである。」
    • ホワイトボックスでの同値分割と境界値分析によって導かれるすべてのケースを網羅すること、ではないのがポイント。それによって外面的な振舞いに影響を与えるものが基本的な検証すべきケース。
@sunaot
sunaot / learning_oop.md
Last active Aug 29, 2015
オブジェクト指向プログラミングの設計について学ぶためのリソースあれこれ
View learning_oop.md
@sunaot
sunaot / designing_class.md
Last active Aug 16, 2018
役割を閉じ込めてそれを名前で表現する (レビューコメントから)
View designing_class.md
  • 入力フォーマット
  • 登録処理の中でのデータモデル
  • 出力フォーマット

が分離していて、それがコード上の構造で表現されているのがよいと思います。 分離すると、どこかで結合しないといけないのでマッピングが発生します。 そこは互いのインターフェイスをどう解釈するかという表現なので明示的になっているほうがよいと思います。


@sunaot
sunaot / comment.md
Created Jan 13, 2015
shared_example ぇぇぇ
View comment.md

たとえば、subject でこのように書けて、

subject { model.errors }
it { is_expected.to be > 0 }

これを DRY にしたくて

View fake_di.rb
class Injectee
def hello
puts :hello
end
end
module DI
class Injector
def initialize(module_object)
@module = module_object
@sunaot
sunaot / keyword.rb
Last active Aug 29, 2015
キーワード引数で引数の委譲や再定義ってどうやるの?って質問したら答えを教えてもらったよ
View keyword.rb
##
# 知りたかったこと
def foo(a: 1, b: 2, c: 3, d: 4)
p a, b, c, d
end
# 1. bar の引数定義を a~d のキーワード引数として foo へすべて委譲したい
# 2. bar の引数定義を a~d のキーワード引数とさらに e: 5 を追加したい
def bar( ??? )
You can’t perform that action at this time.