Rails7 テスト

前回作ったWordbook(リソースフル)のテストを書いてみます。 RailsのテストはminitestをRails用に拡張したものです。

テストの種類

Railsでは、4つのテストが用意されています。

  • 単体テスト(unit test)
  • 機能テスト(functional test)
  • 結合テスト(integration test)
  • システムテスト(system test)

今回の記事ではシステムテストを除いた3つのテストについて書きます。 システムテストは次回の記事で扱います。

日本語訳は書籍によって異なるかもしれません。 例えば「結合テスト」を「統合テスト」と訳すこともあります。 この記事の訳は「Railsガイド]に基づいています。

また、これらの用語は「一般論としてのテスト」にも使われますが、その使い方には幅があります。 Railsの場合は

  • 「単体テスト」は主に「モデルのテスト」や「メーラーの単体テスト」
  • 「機能テスト」は「コントローラのテスト」
  • 「結合テスト」は「複数のアクションの間の流れのテスト」
  • 「システムテスト」は「実際のクライアントとの通信に近い状況をシミュレートして行うテスト」

を指します。

モデルのテスト

モデルのテストでは

  • データベースから読み出しが正しくできているか
  • データベースに保存できているか
  • バリデーションが正しく機能しているか

などをテストします。

これらは、コントローラやビューから切り離して単体でテストすることができます。 その意味では「単体テスト」です。 また、データベースまわりのテストが主になるので、そのためのいくつかの仕組みが用意されています。

フィクスチャ

フィクスチャはいわゆるサンプルデータです。 Yaml形式でデータを記述しておくと、Railsがテスト前にデータベースに保存してくれます。 /test/fixtures/words.ymlに2つほどサンプルデータを書いてみました。

# Word model fixtures

tall:
  en: tall
  jp: 高い
  note: |
    He is tall.
    彼は背が高い。

house:
  en: house
  jp: 
  note: |
    I stayed in my house.
    私は家にいました。

Yamlはコロン(:)でキーと値のペアを表します。 Rubyのデータ構造でいえばハッシュにあたります。

{tall: {en: "tall", jp: "高い", note: "He is tall.\n彼は背が高い。\n"}}
{house: {en: "house", jp: "家", note: "I stayed in my house.\n私は家にいました。\n"}

Yamlの縦棒(|)は次の行からのデータが改行も含めてのデータであることを示します。 :tall:houseはフィクスチャを指定するときの名前になります。 データベースに登録されるデータはenからnoteまでの部分です。

フィクスチャを変数に代入するには、そのモデル名の複数形を小文字で書いたメソッドを用います。

word = words(:tall)

これで変数wordにフィクスチャtallのモデルが代入されます。

モデルのテスト

モデルのテストは/test/models/word_test.rbに書きます。

require "test_helper"

class WordTest < ActiveSupport::TestCase
  test "fixture tall should be read" do
    word = Word.find_by(en: "tall")
    assert_equal "高い", word.jp
    assert_equal "He is tall.\n彼は背が高い。\n", word.note
  end

  test "A valid data should be saved uniquely" do
    w1 = Word.new(en: "room", jp: "部屋", note: "")
    w2 = Word.new(en: "room", jp: "空き", note: "")
    assert w1.save
    refute w2.save
  end

  test "three invalid data should not be saved" do
    w1 = Word.new(en: "", jp: "空き", note: "")
    w2 = Word.new(en: "@@@", jp: "アットマーク", note: "")
    w3 = Word.new(en: "page", jp: "", note: "Turn to page four.\n4ページを開きなさい。")
    [w1, w2, w3].each do |word|
      assert word.invalid?
      refute word.save
    end
  end
end

テストはWordTestクラスの定義の中に書きます。 クラスWordTestActiveSupport::TestCaseのサブクラスです。 さらに、ActiveSupport::TestCaseMinitest::Testのサブクラスです。 したがって、WordTestクラス内では、それらの祖先クラスのすべてのメソッドを使うことができます。

  • Minitest::Testminitestのクラス。 Minitest::Asertionsモジュールをインクルードしている。 minitestで使うアサーションはすべて使うことができる
  • ActiveSupport::TestCaseはRailsのクラスでActiveSupport::Testing::Assertionsモジュールをインクルードしている。 そのモジュールにはRailsで追加した独自のアサーションが定義されている
    • assert_changes
    • assert_difference
    • assert_no_changes
    • assert_no_difference
    • assert_not
    • assert_nothing_raised

アサーションの詳細は上記のリンクやRails Guideを参照して下さい。 また、minitestについては本ブログにも記事があります。 カテゴリー(categories)の「minitest」をご覧ください。

クラス内の各テストを記述するのにtestメソッドを使っています。 これは「”test_“+引数」を名前にしたメソッドを定義します。 つまり、次の2つは同じことになります。

test "show hello" do
  print "Hello world.\n"
end

def test_show_hello
  print "Hello world.\n"
end

testメソッドの引数にはそのテストの内容や目的を書きます。 それによって、defステートメントよりも「テストらしくみえる」「テストの内容を示すことができる」ということが可能です。

2つめのテストを見てみましょう。 ここでは、assertrefuteの2つのメソッドが使われています。 両者ともminitestのメソッドです。

  • assert ⇒ 引数が真ならばテストをパス、偽ならばフェイル
  • refute ⇒ 引数が偽ならばテストをパス、真ならばフェイル

テストがフェイルした場合は、そこでテストは打ち切られ、フェイルのメッセージが画面に出力されます。

test "A valid data should be saved uniquely" do
  w1 = Word.new(en: "room", jp: "部屋", note: "")
  w2 = Word.new(en: "room", jp: "空き", note: "")
  assert w1.save
  refute w2.save
end

w1とw2は英単語が同じで、オブジェクトとしては異なるWordオブジェクトです。 w1をデータベースにsaveメソッドで保存するのは成功しますので、w1.saveは真を返します。 assert w1.saveは成功するわけです。

次にw2を保存しようとすると、バリデーションに引っかかります。 英単語はユニーク、すなわちデータベース中にひとつしか許されませんので、w2は保存できません。 このときsaveメソッドは偽を返します。 refuteは引数が偽のときにパスするので、このテストも通過するはずです。

次に、1番めのテストを見てみましょう。 ここでは、あらかじめデータベースに保存されているフィクスチャの呼び出しをチェックしています。 assert_equalは2つの引数をとり、それらが==であるときにテストをパスします。 テストでは英単語がtallであるデータを読み出して、日本語訳(jp)と備考(note)がフィクスチャと一致するかをテストしています。

3つめのテストはバリデーションのテストです。

  • 英単語(en)は空ではいけない
  • 英単語(en)はアルファベットのみの文字列でなければいけない
  • 日本語訳(jp)は空ではいけない

これらに違反するWordモデルを作成して、invalid?メソッドでインバリッドであるかをテストし、さらにsaveが失敗することをテストします。

このように、モデルのテストは主に

  • 読み書きが正しくできるか
  • バリデーションが正常に機能するか

を見ます。

より複雑なデータベースでは、テーブル間のリレーションが機能しているかどうかもテストします。 ここではそのような複雑なテストについては省略します。

テストの実行

テストの実行はコマンドラインから./bin/rails test (テストプログラム)の形で実行します。

$ ./bin/rails test test/models/word_test.rb
Running 3 tests in a single process (parallelization threshold is 50)
Run options: --seed 543

# Running:

...

Finished in 0.145926s, 20.5584 runs/s, 68.5281 assertions/s.
3 runs, 10 assertions, 0 failures, 0 errors, 0 skips

途中のドットはテストが成功したことを表します。 テストが3つあったのでドットも3つ表示されます。 もしテストがフェイルすればFが、テストプログラムに誤りがあればE(エラー)がドットの代わりに表示されます。

最後の行にテスト結果が出ています。

  • 3 runs ⇒ 3つのテストを実行
  • 10 assertions ⇒ 10個のアサーション(個別のテスト)を実行
  • 0 failures ⇒ 0個のフェイル
  • 0 errors ⇒ 0個のエラー

機能テスト

機能テスト(functional test)はコントローラの動作をテストします。 また、ルーティングとビューはコントローラと一体ですので、それらのテストもここで行うことができます。 テストは/test/controllers/words_contraller_test.rbに記述します。

ルーティングとコントローラのテストとしては

  • HTTPリクエストに対して正しいコントローラとアクションが呼び出されているか
  • コントローラが正しくHTTPレスポンスを返す、またはリダイレクトしているか
  • その他

が考えられます。

また、ビューのテストとしては、正しいHTMLタグが必要数だけ出力されているか、が考えられます。

テスト全体を以下に示します。

require "test_helper"

class WordsControllerTest < ActionDispatch::IntegrationTest
  test "should get index" do
    get words_url
    assert_response :success
  end

  test "should get show" do
    get word_url(words(:tall))
    assert_response :success
    assert_select "nav a", {text: /変更|削除/, count: 2}
    assert_select "nav a.disabled", {text: /変更|削除/, count: 0}

    id = words(:tall).id+words(:house).id
    get word_url(id)
    assert_response :success
    assert_select "nav a.disabled", {text: /変更|削除/, count: 2}
    assert_equal "データベースにはid=#{id}のデータは登録されていません", flash.now[:alert]
  end

  test "should get new" do
    get new_word_url
    assert_response :success
  end

  test "should create word" do
    assert_difference("Word.count") do
      post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
    end
    assert_redirected_to word_path(Word.last)
  end

  test "should get edit" do
    get edit_word_url(words(:tall))
    assert_response :success
  end

  test "should update word" do
    word = words(:tall)
    patch word_url(word), params: {word: {en: "tall", jp: "背が高い", note: ""}}
    assert_redirected_to word_path(word)
  end

  test "should delete word" do
    word = words(:tall)
    assert_difference("Word.count", -1) do
      delete word_url(words(:tall))
    end
    assert_redirected_to words_path
  end

  test "should get search" do
    get words_search_url, params: {search: "."}
    assert_response :success
  end
end

テストを記述するクラスはWordsControllerTestで、ActionDispatch::IntegrationTestのサブクラスです。 なお、このActionDispatch::IntegrationTestは機能テストのクラスのスーパークラスであるだけでなく、結合テストのクラスのスーパークラスにもなっています。 したがって、両テストで同じメソッドを使うことができます。 クラスの親子関係は次のようになります。

WordsControllerTest < ActionDispatch::IntegrationTest < ActiveSupport::TestCase < Minitest::Test

機能テストでは、アサーションが単体テストよりも増えています。

アサーションの詳細は上記のリンクまたはRails Guideを参照してください。

HTTPメソッドをシミュレートするメソッド

機能テストではHTTPメソッドをシミュレートするメソッドを使うことができます。 それらの名前はHTTPメソッドと同じです。 例えばgetはHTTPのGETメソッドをシミュレートします。

get パス名(URL), オプション

の形で用います。 オプションではパラメータなどを渡すことができます。 詳細はAPIリファランスを参照してください。

indexアクションのテストを見てみましょう

test "should get index" do
  get words_url
  assert_response :success
end

getメソッドでwords_urlすなわちhttp://www.example.com/wordsにアクセスします。 なお、words_urlはRailsのヘルパーメソッドで、words_pathのような働きをします。 words_pathが絶対パス/wordsを返すのに対し、words_urlは絶対URLを返します。 他のルーティングprefixに対しても同様のXXX_urlメソッド(XXXはPrefix)を使うことができます。 なお、テストでは仮のホストとしてhttp://www.example.comが用いられています。

このアドレスにGETメソッドでアクセスするとindexアクションにルーティングされます。

assert_responseはHTTPレスポンスのステータスコードをチェックします。 :successは200番台のコードにマッチします。

このテストではindexアクションにアクセスすると200番台のステータスコードでデータが送られてくることを確認しました。 もちろん、もっと詳しくチェックすることも可能です。 例えば、HTMLで送られてくるタグや文字列をチェックすることもできます。 しかし、あまり細かくテストしても意味はありませんから、この程度でも十分だと思います。

getの他に、post、patch、deleteなどのメソッドがあり、それぞれPOST、PATCH、DELETEのHTTPメソッドのリクエストをシミュレートします。 postの例としてcreateアクションのテストを見てみましょう。

test "should create word" do
  assert_difference("Word.count") do
    post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
  end
  assert_redirected_to word_path(Word.last)
end

createアクションへは、あらかじめnewアクションで送られたフォームにデータを書き入れたものをPOSTメソッドで送ります。 そのデータはparamsキーを持つハッシュの形で送ります。

word: { en: "stop", jp: "止まる", note: "" }

これは、word[en]が「stop」、word[jp]が「止まる」、word[note]が空文字列のパラメータを表します。 words_urlhttp://www.example.com/wordsになり、ここにPOSTでアクセスするとcreateアクションにルーティングされます。

ここでは、assert_differenceメソッドでテストしています。 このメソッドは「ブロック実行後の引数の値」から「ブロック実行前の引数の値」を引いた数をチェックします。 デフォルトでは差が1です。 createアクションが実行されると、データベースのWordレコードが1つ増えますから、レコード数「Word.count」の差が1になります。 無事データが保存されればこのテストは通過します。

また、createアクションが成功するとリダイレクトが起こります。 最後に追加したWordモデルのshowアクションにリダイレクトされるので、そのアドレスword_path(Word.last)へのリダイレクトかどうかをチェックしています。 なお、アドレスにword_url(Word.last)を用いても構いません。

削除の場合も同様にassert_differenceを使い、差が-1になるかどうかをチェックします。

ビューのテスト

ビューをテストするにはassert_selectメソッドを使います。 このメソッドはRails guideに書かれていますが、APIリファランスには記述がありません。 このメソッドはRails::Dom::TestingというGemのメソッドです。

これらの情報を参考にしてください。

assert_select CSSセレクタ [, テスト]

という形で使います。

第2引数の「テスト」を省略すると、そのセレクタがHTMLデータに存在すればテストは通過します。 「テスト」がある場合は、そのテスト結果によりパス、フェイルが決まります。 「テスト」は、ハッシュで与えるのが基本的です。

  • :textキー ⇒ そのセレクタ内にある文字列。文字列または正規表現と比較
  • :countキー ⇒ そのセレクタがHTML内にいくつあるかの数値

その他にもありますが、詳細はドキュメントを参照してください。 ここではshowアクションのテストを見てみます。

test "should get show" do
  get word_url(words(:tall))
  assert_response :success
  assert_select "nav a", {text: /変更|削除/, count: 2}
  assert_select "nav a.disabled", {text: /変更|削除/, count: 0}

  id = words(:tall).id+words(:house).id
  get word_url(id)
  assert_response :success
  assert_select "nav a.disabled", {text: /変更|削除/, count: 2}
  assert_equal "データベースにはid=#{id}のデータは登録されていません", flash.now[:alert]
end

フィクスチャのtallをパラメータにしてGETアクセスし、showアクションにルーティングさせます。 レスポンスは正常になるはずですので、assert_responseでチェックします。 その場合「変更」と「削除」メニューが「disabledでなく」表示されるので、2つのassert_selectでテストします。

  • まず、ナビゲーションバーに「変更」または「削除」へのリンク(aタグ)が2個あることをテスト
  • 次に、その「変更」または「削除」へのリンクでdisabledのものは0個であることをテスト

次に「データベースに存在しないid」でshowアクションにアクセスした場合をチェックします。 初期状態ではtallとhouseのフィクスチャのみがデータベースにあるので、それらのidの和であれば、データベースにそのidは存在しないはずです。 そのidをパラメータにしてアクセスすると、レスポンスはsuccessですが、データは表示されません。 また、ナビゲーションバーの「変更」と「削除」リンクはdisabledになっています。 assert_selectでそれをチェックします。 また、フラッシュが表示されるはずなので、assert_equalでフラッシュの内容をチェックします。

今回はshowメソッドのみで「変更」「削除」のenabled/disabledのチェックをしましたが、他のアクションでは常にdisabledのはずなので、それをテストに加えるのも良いと思います。

ビューのテストはあまりしつこくやっても意味は無いのですが、このように画面によってdisabledになるようなリンクをテストするのは有意義です。

結合テスト

結合テストでは複数のアクションがアクセスの流れの中で正しく呼び出されるかをテストします。 機能テストとの違いは、ひとつのアクションのテストか、複数かの違いになります。

まず、雛形を作ります。

$ ./bin/rails generate integration_test word_flows
      invoke  test_unit
      create    test/integration/word_flows_test.rb

/test/integration/word_flows_test.rbにテストを記述します。 ここでは3つの流れについてテストをします。

  • 単語を作成: new ⇒ create ⇒ show
  • 単語を変更: edit ⇒ update ⇒ show
  • 単語を削除: delete ⇒ index

結合テストではリダイレクトのレスポンスが送られたときに、そのリダイレクト先にアクセスするfollow_redirect!メソッドを使います。

require "test_helper"

class WordFlowsTest < ActionDispatch::IntegrationTest
  test "flow from new to show through create" do
    # access to the new action
    get new_word_url
    assert_response :success
    # access to the create action
    post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
    assert_response :redirect
    follow_redirect!
    # redirect to the show action
    assert_response :success
    assert_equal "単語を保存しました", flash[:success]
    assert_select "ul.list-group" do
      assert_select "li", "stop"
      assert_select "li", "止まる"
      assert_select "li", ""
    end
  end

  test "flow from edit to show through update" do
    # access to the edit action
    word = words(:tall)
    get edit_word_url(word)
    assert_response :success
    # access to the update action
    patch word_url(word), params: { word: { en: "tall", jp: "背の高い", note: "How tall is she?\n彼女はどのくらい背がありますか?" } }
    assert_response :redirect
    follow_redirect!
    # redirect to the show action
    assert_response :success
    assert_select "ul.list-group" do
      assert_select "li", "tall"
      assert_select "li", "背の高い"
      assert_select "li", "How tall is she?\n彼女はどのくらい背がありますか?"
    end
  end

  test "flow from delete to index" do
    # access to the delete action
    word = words(:house)
    delete word_url(word)
    assert_response :redirect
    follow_redirect!
    # redirect to the index action
    assert_response :success
    assert_select "h1", "単語帳"
  end
end

最初のテストだけ説明すれば十分だと思います。 2番めと3番めについてはソースコードを追ってみてください。

最初のテスト部分を再掲します。

test "flow from new to show through create" do
  # access to the new action
  get new_word_url
  assert_response :success
  # access to the create action
  post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
  assert_response :redirect
  follow_redirect!
  # redirect to the show action
  assert_response :success
  assert_equal "単語を保存しました", flash[:success]
  assert_select "ul.list-group" do
    assert_select "li", "stop"
    assert_select "li", "止まる"
    assert_select "li", ""
  end
end
  • getメソッドを使い、newアクションにアクセスする
  • 応答はsuccess。入力フォームが表示されるがそのチェックは省略
  • 単語stopをパラメータにセットしてpostメソッドでcreateアクションにアクセス
  • 応答はredirect
  • follow_redirect!メソッドでリダイレクト先(showアクションになるはず)にアクセスする
  • 応答はsuccess
  • 「単語を保存しました」のフラッシュが表示されるはずなのでassert_equalでチェック
  • 保存された単語が順序なしリストで表示されるはずなので、それをチェック。 まず、assert_selectul.list-groupセレクタをキャッチする。 そのブロックでは、キャッチされたセレクタ内のみを対象としてassert_selectが働く。 リストの項目として「stop」「止まる」「」(空文字列)があるはずなのでチェック。 なお、assert_selectの第2引数が文字列のときは、そのセレクタ(HTMLタグ)で囲まれたコンテンツの文字列との一致をチェックする

このようにして、複数のアクションにまたがるフローをチェックできます。

結合テストではクライアントのリクエストをシミュレートしてそれに対する応答をチェックしました。 しかし、現実にはブラウザで表示された画面の中でボタンやリンクのクリックなどが行われます。 そこまでのシミュレートは結合テストではできません。 そのチェックはシステムテストならば可能です。 次回はシステムテストについての記事を掲載する予定です。

2023

単項マイナスと構文解析

1 minute read

単項マイナスとは 単項マイナスと括弧 括弧なし単項マイナスを許容する場合のBNF calcの場合

Raccライブラリと構文解析

3 minute read

パーサ・ジェネレータとは 少し複雑な文法 四則(加減乗除)計算のBNF Racc で実装 クラス定義、BNFの記述部分 ヘッダー、インナー、フッター コンパイルと実行 演算子の優先順位と結合における左右の優先順位 まとめ

StrScanライブラリと字句解析

less than 1 minute read

StrScanライブラリのドキュメント 字句解析とは StrScanライブラリ StrScanライブラリを使った字句解析 実例

Gem

1 minute read

lbtというgemを作って公開してみた lbtはどんなgemか ファイルの配置 lbt.gemspec Rakefile gemのビルド RubyGems.orgへのアップロード 補足・・rake/gempackagetaskサブライブラリについて

Encoding

1 minute read

文字列のエンコーディングに頭を悩ませることはほとんどなくなりました。 なぜなら、どのアプリ、システムもUTF-8を使うようになったからです。 Rubyでもエンコーディングの問題が起こることはまず無いでしょう。 ですが、今回はエンコーディングの考え方を整理してみたいと思います。

Thread

less than 1 minute read

Fiberを書いたときから、次はスレッドを書こうと思っていましたが、時間がかかってしまいました。 その理由は、期待したとおりのスレッドの効果がなかったためです。 今回はそのことを書きますが、これはRubyのスレッドの抱えている問題なのか、自分のやり方が悪いのかははっきりしていません。

Fiber

1 minute read

Fiberは「ノンプリエンプティブな軽量スレッド」とRubyのマニュアルに記載されています。

RDoc

less than 1 minute read

今回はRubyプログラムから自動的にドキュメントを作成するRDocについて書きたいと思います。 私はこのことについて、エキスパートではありません。 この記事も、初心者の体験談だと考えてください。

Back to Top ↑

2022

Ruby/GTK4

5 minute read

Ruby/Gtkの記事を先日書いたときに、「これはかなり使える」という手応えを感じたので、WordBook(Railsで作った単語帳プログラム)のGTK 4版を作りました。 プログラムは「徒然なるままにRuby」のGitHubレポジトリに置いてあります。 レポジトリをダウンロードし、ディレクトリ_example/...

Shoes – Rubyとグラフィック

5 minute read

Rubyはグラフィックについて弱い印象があります。 しかし、グラフィックはデバイスに関することなので、言語そのものには直接の関係はないはずで、あるとすればライブラリです。 今後グラフィック関係のgemが開発されることに期待しましょう。

Rails7 テスト

5 minute read

前回作ったWordbook(リソースフル)のテストを書いてみます。 RailsのテストはminitestをRails用に拡張したものです。

Rails7 モデルとデータベース

5 minute read

今回はRailsにおけるデータの作成と保存、そして変更について説明します。 そのベースになるモデルとデータベースの話から始め、appendとchangeの動作について詳しく説明します。

Rails7とBootstrap

3 minute read

一般に、HTMLは文書の構造を表し、CSSはその体裁(見栄え)を表します。 Railsは最終的にCSSを含むHTML文書を出力するので、この2つについての理解が必須です。 この記事ではとくにCSSの人気ライブラリであるBootstrapを紹介します。 BootstrapはJavascriptも含んでいます。

Rails7のインストール

2 minute read

Rubyの最も人気のあるアプリケーションであるRuby on Railsを取り上げようと思い、書き始めました。 予想してはいましたが、相当な分量になってしまいました。 そのため、何回かに分けて記事にすることにします。 また、対象となる読者のレベルをどうしようかと考えましたが、「徒然Ruby」が基礎的な内容から始ま...

GemとBundler

1 minute read

Rubyのライブラリ管理システムのRubygemsとコマンドgemおよびbundlerについて説明します。

minitest(3)モックの詳細

1 minute read

minitestについて連続して2回書いてきました。 「minitestはドキュメントが少ない」という人がいますが、私も同感です。 例えば、モックとスタブの説明も少ないです。 そこで、今回はmock.rbのソースコードを参考に、モックの私的ドキュメントを書いてみました。 あくまで私個人の考えであり、minites...

minitest(1)テストとは

2 minute read

アプリ作成の記事でminitestを使いました。 今回はminitestについて、また一般にテストについて、私の考えを書こうと思います。

public、private、protected

2 minute read

今回はメソッドの呼び出し制限ついて説明します。 呼び出し制限にはpublic、private、protectedの3つがあります。

アプリ制作、インストール、テスト

1 minute read

2023/10/29 追記:この記事は新しく書き直しました。 古い記事で使っていたGitHubのCalcが大幅にアップデートされたためです。 そこで、この記事に合うようなプログラムsimple_calcを新たに作りました。 このプログラムは本レポジトリの_example/simple_calcにあります。

case文

2 minute read

if〜elsif〜・・・〜else〜endは皆さん良く使うでしょうか? これは場合分けで良く使われる方法です。 これと同様の制御構造にcase文があります。 Cのswitch文に似ていますが、より強力な機能を持っています。 if-else-endよりも高い能力があるといえます。

Lambda

2 minute read

Procオブジェクトを生成するメソッドlambdaについて説明します。

Proc オブジェクト

2 minute read

今回はブロックを一般化したオブジェクトProcを説明します。

モジュール

1 minute read

モジュールには名前空間とミックスイン(Mix-in)の2つの機能があります。 ここではミックスインについて説明します。

Kernelモジュール

less than 1 minute read

Kernelモジュールのメソッドはどこでも使うことができます。 そのメソッドの中には便利で有用なものが多いです。

便利なメソッド

1 minute read

ここでは私が便利だと思ったメソッドを紹介します。

文字列と正規表現

3 minute read

文字列は最も使うオブジェクトのひとつです。 特にウェブ・アプリケーションでは、コンテンツだけでなくHTMLのタグやCSSを含めすべてが文字列です。 Rubyは文字列オブジェクトのメソッドが充実しており、またパターンマッチのための正規表現も充実しています。

配列

2 minute read

配列は、どのプログラミング言語にもあると思います。 複数の要素を一括して扱うことができるのが配列です。 Rubyの配列はメソッドが充実しているので、プログラムを効率的、機能的に書くのに役立ちます。

トップレベルのメソッド

1 minute read

今回はメソッド定義です。 メソッド定義はRubyの核心ですが、今回はトップレベルに限って説明します。 この限定によって、内容はかなり易しくなっています。

ブロックとイテレータ

less than 1 minute read

ブロックはRubyの特長です。 ブロックのおかげで記述が非常にすっきりと分かりやすくなります。 今回はブロックをイテレータの本体として使う方法を説明します。

整数

less than 1 minute read

ここではRubyの最も基本的なオブジェクトである整数について説明します。

Hello world

less than 1 minute read

「徒然なるままに」をネットで調べてみると、「することもなく、手持無沙汰なのにまかせてという意味」とありました。 まさに、自分の現状を言い当てた言葉。 しかも、ブログに書くネタもなかなか思いつかない日々。

Back to Top ↑