社内SEの独り言

WEBの学びをつらつらと書いていきます

単体テスト項目書書こう

単体テストに関するメモ

今回自身が製造を実施したFAX機能について、単体テストを行うことになったので備忘録としてメモ。

単体テストとは

調べてみると、プログラム作成後に最初に実施するテストであり小さな単位で実施するテストである。

だそうです。んー、プログラムのメソッド単位とかでテストを行うってことだと解釈。

// 帳票作成処理
        public List<SendFaxModel> CreateSampleReport(List<GetFaxConModel> conList)
        {
            // 初期化
            List<SendFaxModel> dataList = new List<SendFaxModel>();
            RV_sample001Accessor sample001 = new RV_sample001Accessor();
            RV_sample002Accessor sample002 = new RV_sample002Accessor();

            try
            { 
                // グループ化
                var conListdev = conList.GroupBy(x => x.SupplierCD);
         
                // 帳票データを取得
                List<sample01> dataSample001 = sample001.GetRV_sample001();
                List<sample02> dataSample002 = sample002.GetRV_sample2();

                // 帳票作成
                foreach (var con in conListdev)
                {
                    DateTime dt = con.Select(x => x.ShipDate).First();
                    SendFaxModel data = new SendFaxModel();
                    List<ReportInfo> rpInfo = new List<ReportInfo>();

                    var sample001Reportlist = dataSample001.Where(x => x.SupplierCD == con.Key).ToList();
                    var sample002Reportlist = dataSample002.Where(x => x.SupplierCD == con.Key).ToList();

                    // 作成(帳票名、帳票パス) 
                    rpInfo.Add(Createsample1Report(sample001Reportlist));

                    // 作成(帳票名、帳票パス)
                    rpInfo.Add(Createsample002Report(sample002Reportlist));

                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
            return dataList;
        }

例えばこんな帳票作成を実施する処理を担うCreateSampleReportメソッド1つの中身に対してテストを実施するような感じ。さて、このメソッドのテストをどのように実施したらよいのだろう、どんなテストケースをあげたらよいのだろう。ぐぐった結果、ホワイトボックステストブラックボックステストというのがあるらしい。

ホワイトボックステスト

上記のメソッド内のソースを上から下まで通してうまく動くかを見ていく。

網羅条件(どの程度網羅させるか)とかをチョイスする必要があり。(命令網羅、分岐網羅、条件網羅など)

ブラックボックステスト

プログラムの中身をスルーして、仕様書から何をインプットしたら何をアウトプットするという予想を立てて

その通りの結果になることを確認するテスト?

今回の例でいえば、条件で日付を与えたりしているので、2021年09月07日という条件を与えた場合にテストデータとして登録されている2021年09月07日のデータの帳票が指定された帳票パスに生成されればよいということになる。テストのバリエーションとしてはインプットとなるテストデータを変えて実施する。

(境界値分析、同値分割法など)

んーつまりは、各メソッドについてインプットとなる引数に網羅的なテストデータ(境界値などを満たす)を用意してアウトプットが期待通りに出たらテストとしてOKっていうことかな。いってしまえば入力と出力だけ見るってことか。

なるほどなー、仕様理解してないとテストできないわけだw

多分とっつきやすいのはブラックボックステストかな?想定されるユースケースで求める結果が出るかをテストする仕様に準ずるテストだしなあ。ホワイトボックスは結構やりだしたら人的コスト半端なさそう、網羅具合にもよるけど。

ここはコストにもよりそうね。うーん難しい。ただちょっと調べたおかげでテスト項目書を書く参考になった気がする。 参考

Railsとかのテストはなんかまただいぶ違いそうだけども。

form_with

form_withのmodel指定について

= form_with model: [post, comment], class: 'd-flex mb-0 flex-nowrap justify-content-between', remote: true do |f|
  = f.text_field :body, class: 'form-control input-comment-body', placeholder: 'コメント'
  = f.submit '投稿', class: 'btn btn-primary btn-raised'

コメント投稿の機能を実装する部分。

コメント投稿機能のルーティングは以下の通り。(shallowルーティング)

resources :posts, shallow: true do
    resources :comments
  end

コメント投稿のroutesは、http://localhost:3000/rails/info/routesを見ると

post_comments_path POST /post/:post_id/commentsとなっているため、modelが複数必要となる。

(コメントだけなのでcommentだけで良いのでは?と思ったので調べた。)

modelの指定順番も注意

model [comment, post]とすると以下のようにパスが違うよって言われる。

このルーティング、あったらあったで特定のコメントの先に投稿があるようでちょっと面白いSNSかも・・・