RailsとRedmineプラグインの作り方についてやっとある程度分かるようになってきました。当初目標はコンプリートしていませんが(テストの途中で立ち往生気味)、その模様は次のWikiにあります。5.2)で動作するよう修正する作業に入りました。こちらは1週間でほぼ作業を終えました。この修正作業のまとめを次のブログに記載しました。Qiita修正作業の過程は次のチケットにメモを残しています。Torutk今後、用語集プラグインのメンテナンスをできるようにするためには、構造を分かりやすくするリファクタリングをしていきたいので、そのためにはテストが不可欠となります。RailsのテストMinitestかRSpecかRails標準のテストは、Minitestと呼ばれるテストフレームワークを使ったものです。Redmineプラグイン開発やRailsの開発関係の記事などでは、別途RSpecを推奨しているものを多く見かけます。扱うブログも多数見つかります。Railsを使ったプログラム(Redmienプラグイン)の開発知識を得るために買った次の書籍でも、テストの章ではRSpecを「デファクトスタンダードである」として採用しています。見る2015年の関西Ruby会議06での次のセッション資料では、「両方使ってみて判断する」とまとめられています。RSpecとMinitest使うならどっちテストコードの書き方(API)については、Minitestはassertを使ったテスト判定を行うので、CppUnitやJUnit(バージョン3まで)などのユニットテストフレームワークで用いられているassertによるテスト判定に慣れていると障壁を感じることなくMinitestのAPIに馴染めます。RSpecは内部DSLで独特の書き方を覚える必要があります。テストデータの準備については、Minitestの特徴であるfixturesを使った、テストデータをYAMLで記述しテスト実行時に読み込みテストコードで利用する方法と、RSpecではFactoryBotでテストデータを生成する方法となり、分かりやすさは圧倒的にfixturesです。モデルのテストではデータベースの制約・整合性テストをする必要があり、異常値(制約違反データ)をデータベースに入れてわざとエラーを発生させることがfixturesでは出来ないため、RSpec(FactoryBot)がいいという話も見かけました。モックについてはRSpecに軍配が上がる(Minitestにはモックがない?)ようでうs。いうことで、どちらを選ぶかは、やはりトレードオフとなるようです。今回はトレードオフの主項目を、学習障壁が低いこと(環境構築の手間と覚えることが少ないこと)とし、テストコードが増えてもよしとし、Minitestを使って進めることとします。RubyやRailsで覚えることだらけの現状では、RSpecの書き方をさらに覚えるのはアップアップ気味で辛さを感じてしまいます。モデルのテストについてそもそもモデルクラスをどう構成するかモデルのテストを探っていたところ、そもそもMVC構造におけるMの役割にぶち当たりました。Railsのモデルは一般的にはActiveRecordですが、これはO/Rマッパーで、ドメインモデルとしてビジネスロジックを持たせるかどうかについてはRails界隈で議論になっているようです。Railsに限らず、MVC的な構造を取るとよく陥るのが肥大化したコントローラーです。Webアプリケーションではなく、GUIアプリケーションや、ヘッドレスな通信処理アプリケーションなどでも、コントローラーでイベントの受理から応答を返すための集計・加工など(いわゆるビジネスロジック)を手掛けてしまいあっという間に数百〜千行超と肥大化することがあります。その解決の一方法として、O/Rマッパー部分のActiveRecord継承クラス(物理モデル)と、ビジネスロジックを持つ論理モデルに分割し、コントローラーからは論理モデルにアクセスするという設計があります。論理モデルをクラスとして別定義する。コントローラーからは論理モデルにのみアクセス、物理モデルは論理モデルからのみアクセス可能とする。論理モデルをモジュールとして別定義し、ActiveRecord継承クラスでincludeする。コントローラーからはモジュールに定義したメソッドを呼び出し、ActiveRecord継承クラスのメソッド(属性)には触らない。後者が推奨される模様です。ActiveRecord継承クラスのテストvalidationのテストデータベースの整合性テスト(制約、外部参照など)をテストします。テストデータは、fixtureで用意すると制約違反なデータは用意できないので、まずfixtureでは制約を守ったデータを用意し、テストメソッドでカラムに制約違反となる値を入れてvalidをassertで確認するよウニテスト記述します。endここで、invalidのテストをするにあたり、前提としてモデルクラスでvalidateされている属性となります。モデルクラスでvalidateしていないでデータベースの制約がかかっている場合、valid?はtrueになりますが、モデルをsaveすると例外が発生します(例、ActiveRecodrd::NotNullViolation)。validationで必須指定をしていないがデータベース上はNOT_NULL制約をかけている属性(カラム)については、次のようなコードでテストできます。endビジネスロジックを実装したモジュールのテストメソッドをテストします。テストのデバッグユニットテストを実行して問題が発生したときに、その場所での変数の値を確認したり、ステップ実行させることができると重宝します。いうかそれができない開発環境は貧弱です。Rubyでは、pry-byebugライブラリを使い、ブレークポイントを置きたいコード上にbinding.pryと追記するとそこでブレークしてコマンド待ち(REPL)となります。9はてなブログをはじめよう!torutkさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。