SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

5分でわかるActiveReports帳票

5分で"もっと"わかるActiveReports帳票(2008年度版)-帳票完成時にチェックしておきたいポイント集

第3回 テスト時に気をつけたい印刷物のチェックポイント

  • このエントリーをはてなブックマークに追加

本連載では帳票作成コンポーネント「ActiveReports for .NET 3.0J」をさらに使いこなすためのテクニックを紹介していきます。今回は帳票アプリケーションが完成し、実際に印刷してテストする際にチェックしたいポイントをいくつか解説します。

  • このエントリーをはてなブックマークに追加
編集部注

 本稿はActiveReportsの旧バージョンを用いた内容となっています。最新版に基づいた記事は連載の目次「5分でわかるActiveReports帳票」をご参照ください。

はじめに

 ActiveReports for .NET(以下ActiveReports)は、Visual Studioと統合された使いやすいレポートデザイナや、高機能なレポートビューア、多彩な出力形態をサポートする帳票作成コンポーネントです。今回はActiveReportsを利用して開発した帳票アプリケーションをテストするときに、気をつけたいポイントについて紹介していきます。

これまでの記事

対象読者

  • Visual Basic 2008またはVisual C# 2008を使ってプログラムを作ったことのある方。
  • 帳票作成ツールに興味のある方。

必要な環境

開発ツール
  • Visual Studio 2008
  • Visual Studio 2005(※Windows Vistaで開発する場合はVisual Studio 2005 Service Pack 1 Update for Windows Vistaの適用が必要です)
  • Visual Studio .NET 2003
 Visual Studio 2005/2008 Express EditionではActiveReportsをインストールできません。

帳票アプリケーションのテスト

 本連載ではこれまで、ActiveReportsの機能を利用した帳票アプリケーションの開発方法について紹介してきました。しかし、アプリケーションの開発はプログラミングが終わったら即、終了というわけにはいきません。開発したアプリケーションは当然、仕様どおりに動作するかどうかをテストする必要があります。

 最近ではテストの自動化ツールも普及し、アプリケーションロジックの動きを1つ1つ確認しながら開発を進めていくTDD(Test-Driven Development: テスト駆動開発)と呼ばれるスタイルも少しずつ広まってきました。Visual Studioにアドオン可能な単体テストツールとしてはNUnitが有名ですが、Visual Studioの上位エディション(Professional EditionおよびTeam Edition)には、単体テストツールが標準で付属しています。帳票アプリケーション開発でも、データベースへのアクセスやファイル入出力などの処理はこれらの単体テストツールを活用しやすい部分です。しかし、すべてのテスト項目がツールで自動化できるわけではありません。

 帳票アプリケーションの分野は「出力を紙に印刷する」ことが最終的なゴールになるため、帳票を印刷してから出力項目を1つずつ確認していくという作業はどうしても必要になります。そこで今回は「帳票アプリケーション開発で、ここはチェックしておきたい」と思われる項目をいくつか、Tips形式で紹介していきたいと思います。

コントロール項目のテスト

 帳票アプリケーションのテスト項目のうち、最も基本的なテストはコントロール項目のテストです。コントロール項目のテストでは、ActiveReportsのレポートファイル上に配置した各コントロールが、データソースのフィールドと正しくバインドされているかどうかを確認します。

 ActiveReports 3.0Jではレポートデザイナのプレビュー機能が強化されたこともあり、データのバインドを確認するのは以前よりも楽になりました。しかし、コントロール項目のテストはデータバインドの接続確認だけではありません。

 ここでは、DataFieldプロパティ以外にも必ずチェックしておきたい項目について紹介したいと思います。

フォントは統一されているか

 コントロール項目のテストと言うと「値が正しく表示されているか」ということが気になるあまり、意外と見落としがちなのですが、まずは、フォントが正しく指定されているかを確認しましょう。

 ActiveReportsのLabelコントロールやTextBoxコントロールでは「MS UI Gothic」の10ポイントがデフォルトで設定されていますが、帳票で出力するフォントとしてはディスプレイで読みやすいゴシック系フォントよりも、印刷したときに読みやすい明朝系フォントを指定することが多いです。特に、1つの帳票の中で複数のフォントを使い分けているような場合はフォントの設定忘れが原因で、表示されているフォントが出力されたデータ項目ごとに違っていることがあります。

 レポートヘッダに表示するタイトル文字、ページヘッダやグループヘッダに表示する列ヘッダ、Detailセクションの出力値、フッタに表示するページ番号など、設定忘れがないかを確認してください。特に、小さなフォントで出力しているときは、プレビュー画面で等倍表示(100%)しているとフォントの違いがよくわからないことがあります。そのような場合は倍率を200%~300%くらいまで拡大すると、スクリーンでもかなり見やすくなります。

フォントが統一されていない例
フォントが統一されていない例
フォントが統一されている例
フォントが統一されている例

 フォントの設定忘れが見つかった場合、レポートデザイナに配置されたたくさんのコントロールを1つ1つ選んでプロパティウィンドウからフォントを設定するのはとても面倒です。CtrlキーまたはShiftキーを押しながらコントロールクリックすると、複数のコントロールを同時に選択状態にすることができます。この状態でフォントを指定すると、選択されたすべてのコントロールに同じフォントが設定されるので便利です。

サイズと折り返し設定は適切か

 LabelコントロールやTextBoxコントロールは、ActiveReportsを使う上で最も基本的なコントロールです。単に文字列を表示するだけであれば、DataFieldプロパティにデータソースのフィールド名を指定するだけで、値を表示させることができます。

 ここで気をつけたいのは、コントロールのサイズと折り返しの設定です。表示する文字列が短いときは問題なく表示されるので気づきにくいところですが、表示する文字列が長くなったときに、レポートデザイナに配置したコントロールのサイズが足りないと、文字列が途中で切れてしまったり、予期せぬ折り返しによってレイアウトが乱れることがあります。表示のテストでは必ず、そのコントロールで表示する最も長い文字列を指定して、表示の乱れがおきないように確認してください。

 また、使っているフォントが「プロポーショナルフォント」の場合は文字(グリフ)ごとに幅が異なります。テストに使う文字列は「I」のような幅の狭い文字よりも、「W」のように幅の広いものを使うようにしましょう。日本語の場合はアルファベットほど文字の幅に差はありませんが、「□」のような幅広の記号を使うのがおすすめです。

 コントロールのサイズ調整と折り返しを制御するには、LabelコントロールやTextBoxコントロールのCanGrowプロパティとWordWrapプロパティを設定します。文字列の長さにあわせてコントロールのサイズを動的に調節したい場合は、CanGrowプロパティとWordWrapプロパティをTrueに設定します。逆に、レイアウトのほうを固定したい場合は、これらのプロパティがFalseになっていることを確かめてください。

折り返し、はみ出しの例(CanGrow=True、WordWrap=True)
折り返し、はみ出しの例(CanGrow=True、WordWrap=True)
折り返し、はみ出しの例(CanGrow=False、WordWrap=True)
折り返し、はみ出しの例(CanGrow=False、WordWrap=True)
折り返し、はみ出しの例(CanGrow=False、WordWrap=False)
折り返し、はみ出しの例(CanGrow=False、WordWrap=False)

書式は設定されているか

 数量や金額など数値型のデータを表示する場合、帳票では単に「12345678」と出力するのではなく、「\12,345,678」のような書式をつけた形で出力するのが一般的です。数値型のデータに書式をつけて表示するにはTextBoxコントロールを使い、OutputFormatプロパティに書式文字列を設定します。

 書式文字列はプロパティウィンドウで直接指定することもできますが、入力欄の右側に表示される「…」ボタンを押すと表示される「出力書式の設定」ダイアログから目的にあったものを選択することでも指定できます。また、数値や金額は右寄せのレイアウトで配置することが多いです。Alignmentプロパティで「Right」が設定されているかどうかも確認しておきましょう。

書式の有無による出力の違い(書式なし、デフォルトの左寄せ)
書式の有無による出力の違い(書式なし、デフォルトの左寄せ)
書式の有無による出力の違い(書式つき+右寄せ)
書式の有無による出力の違い(書式つき+右寄せ)

改ページとセクションレイアウトのテスト

 出力項目1つ1つの確認が終わったら、次は「各セクションの配置と改ページ制御のテスト」に移ります。

 標準出力へ結果を書き出す「コンソールアプリケーション」や、出力したHTMLをWebブラウザ表示する「Webアプリケーション」とは異なり、帳票アプリケーションの出力には「ページ」という概念を考慮に入れなければなりません。

セクションのページ分割を避ける

 ActiveReportsでは1件分のデータを出力する単位として「Detailセクション」が使われますが、この他にもDetailセクションに列ヘッダを付与したり、グループ単位で集計結果を出力するための各種ヘッダ、フッタセクションも用意されています。

 ヘッダ・フッタセクションには1回だけ出力される「レポートヘッダ・フッタ」、毎ページの先頭・末尾に必ず出力される「ページヘッダ・フッタ」、Detailセクションの集計単位で出力される「グループヘッダ・フッタ」の3種類があります。

 ActiveReportsでは出力先の用紙サイズに合わせてこれらの各セクションを配置していきますが、ページの残りサイズが少ない場合は1つのセクションが途中で改ページされ、2ページに分割されてしまいます。セクション途中の改ページを避けるには、各セクションのKeepTogetherプロパティをTrueにします。

セクションが分割されてしまった例(商品説明が次ページへ持ち越されている)
セクションが分割されてしまった例(商品説明が次ページへ持ち越されている)

ページ下部の余白を避ける

 各セクションのKeepTogetherプロパティをTrueに設定すると、1つのセクションが2ページに分割されるのを避けることができます。しかしこの方法でセクション分割を避けると、各ヘッダ、フッタセクションの高さやDetailセクションの数によっては、ページの下部に余白ができてしまうことがあります。

 帳票の要件によっては、このような余白は好まれないこともあります。特に罫線の多い帳票では余白の領域が目立つため、出力ミスのように見えてしまうこともあります。

セクションの高さによっては、ページ下部に余白ができる(2ページ目のページフッタ上)
セクションの高さによっては、ページ下部に余白ができる(2ページ目のページフッタ上)

 改ページによる余白の発生を避けるには、できるだけ各セクションの高さを揃え、各ヘッダ・フッタの出現回数やDetailセクションの出力数によってページの「あまり」が発生しないように工夫する必要があります。同時に、各セクションは高さを固定し、出力データの文字列長にあわせてコントロールが拡張されないように設定してください。

セクションの高さをそろえて、余白を減らす
セクションの高さをそろえて、余白を減らす

 このようにセクションを調整したうえで、ヘッダ・フッタの出現パターンを網羅したテストケースを作成して、1つ1つ確認していきます。

ページの先頭に来るヘッダセクションの組み合わせ例
  • レポートヘッダ+ページヘッダ
  • ページヘッダ+グループヘッダ
  • ページヘッダのみ
ページの末尾に来るフッタセクションの組み合わせ例
  • ページフッタのみ
  • グループフッタ+ページフッタ
  • レポートフッタ+ページフッタ
  • グループフッタ+レポートフッタ+ページフッタ

 この他、Detailセクションの件数がゼロ件のときに発生する「ヘッダだけのセクション」や「フッタだけのセクション」、改ページ制御のミスが原因で発生する「白紙の出力ページ」がないかも確認してください。

印刷のテスト

 改ページ制御と同様、帳票アプリケーションのテストで避けて通れないのが、「結果を紙に印刷して確認する」というプロセスです。

 コンソールアプリケーションやWebアプリケーションの場合、結果はコンソールやWebブラウザに出力されるため、出力された内容は画面上で確認すればOKです。しかし、帳票アプリケーションの場合は必ず紙に印刷された結果を目で見て確認しなければなりません。

 コンソールアプリケーションが画面やファイルに結果を出力する速度や、WebアプリケーションがHTMLをレンダリングする速度に比べると、プリンタが帳票を印刷するスピードは圧倒的に遅くなります。また、帳票アプリケーション開発者のすべてが、自分の手の届くところにプリンタを置いているわけではないと思います。印刷結果を確認するたびに席を離れてプリンタのところまで行くのでは、開発効率が上がるはずもありません。

印刷結果はPDF出力ですばやく確認

 「帳票アプリケーションの出力は紙で確認しなければならないが、いちいちプリンタで印刷するのは効率が悪い」

 一見矛盾するこの2つの問題を同時に解決するには、印刷結果をファイル出力する「仮想プリンタ」を使うと便利です。

 仮想プリンタとはOS上でプリンタとして認識されるソフトウェアのことです。仮想プリンタに送られたプリントジョブはGIFやJPEGなどの画像やPDF形式に変換されるため、出力結果をファイルとして取り出すことができます。仮想プリンタには有償、無償を含めさまざまな種類のものがありますが、ここでは出力結果をPDFに変換するフリーウェア「PrimoPDF」を紹介したいと思います。

 PrimoPDFのダウンロードページからインストーラをダウンロードして実行すると、コントロールパネルのプリンタ一覧に仮想プリンタが追加されます。出力した帳票を印刷するときに、プリンタとしてこの「PrimoPDF」プリンタを選択すると、PrimoPDFのファイル出力ダイアログが表示されます。ここでファイルの出力先を指定して「PDFの作成」ボタンを押すと、印刷結果がPDFファイルとして保存されます。

PrimoPDFをインストールすると、仮想プリンタが登録される
PrimoPDFをインストールすると、仮想プリンタが登録される
PrimoPDFのファイル出力ダイアログ
PrimoPDFのファイル出力ダイアログ

最後は紙で確認しよう

 前項では、帳票アプリケーションの出力結果を仮想プリンタに出力して確認する方法を紹介しましたが、これは「紙資源の節約」や「時間的な効率」といった目的からやむを得ずとった方法です。最後はやはり、実際と同じ用紙に出力して確認するようにしましょう。

 ActiveReportsでは画像や罫線を含む表現力豊かな帳票を作成できますが、帳票の種類によってはあらかじめ書式や罫線、企業ロゴの入った特別な用紙が使われることもあり、アプリケーションでは罫線を引かず数値や文字だけを出力するケースもあります。用紙の方に枠や罫線が印刷されているタイプの帳票では、実際に出力してみないことには出力位置のズレやはみ出しを確認することができません。

おわりに

 今回は、帳票アプリケーションのテストで気をつけたいポイントについて解説しました。次回は、「用途に合わせたデータソースの選択」というテーマでお送りする予定です。お楽しみに。

 

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/2618 2015/06/04 12:59

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング