TeraTerm用のマクロファイル「**.ttl」ファイルを実行すると「無効なホスト」と表示された場合の対処方法についてメモしておきます。
ttlファイル用の実行ファイルを「ttpmacro.exe」へ変更します。
JUnitで使用可能なアノテーションの種類についてまとめておきます。
| アノテーション | 用途 |
|---|---|
| @Before | メソッド単位で事前実行する |
| @BeforeClass | テストクラスで一回だけ事前実行 |
| @After | メソッド単位で事後実行する |
| @AfterClass | テストクラスで一回だけ事後実行 |
| @Rule | テスト時における一時的なルールの作成 |
| @ClassRule | 複数のテストを通じてのルール設定 |
| @Test | テストメソッドの指定 |
| @Ignore | 一時的にテスト対象外メソッドを指定 |
業務でSQLを使用する場合、必ず使用する事になると言って良いのがテーブルの結合処理です。WEB系システムの場合、そのほとんどはRDBMSを使用してますのでテーブルが一つだけなどという事はまずありえません。複数のテーブルからその時々に応じて必要なデータを取得し使用するのが常です。その際に重要になるポイントの一つが内部結合と外部結合です。
|
1 2 3 4 |
SELECT goods.type_code, goods.name, type_code.code_name FROM goods INNER JOIN type_code ON goods.type_code = type_code.code; |
|
1 2 3 4 |
SELECT goods.type_code, goods.name, type_code.code_name FROM goods LEFT OUTER JOIN type_code ON goods.type_code = type_code.code; |
Web系の開発していると画面表示確認する際に、「cssやjsは変更したのに画面を表示してみると反映されていない」という事を経験した方は少なくないと思います。
こういう場合はまず、F5もしくはctrl+F5を押下して画面を再表示（リロード）確認すると思いますが、そもそも「F5単独」押下と「ctrl+F5同時」押下では何が違うんだろう？という事についてメモしておきます。
 |
 |
|
上記で説明している「更新ボタン」ですが、以下の様にブラウザのアドレスバー付近に表示されている以下のような赤枠内のボタンのことを「更新ボタン」と記載しております。
サーバー側制御（キャッシュ制御ヘッダー）との関係
ブラウザの「F5」や「Ctrl＋F5」によるリロードは、あくまでクライアント（ユーザー側ブラウザ）での操作です。ですが、本番環境ではサーバー側・ホスティング側で HTTP ヘッダー（例：Cache-Control、Expires、ETag）を設定して「ブラウザにいつまでキャッシュを使わせるか」「変更時には必ず再取得させるか」といった制御が行われています。
→ たとえば、Cache-Control: no-cache, no-store や Pragma: no-cache を設定しておくと、ユーザー側が「F5」だけでも常に最新取得がされるよう促せる場合があります。
→ 逆に、長めにキャッシュを許す設定がされていると「Ctrl＋F5」などをしない限り古いリソースを参照し続ける可能性があります。
開発／ステージング vs 本番環境の使い分け
開発中は「Ctrl＋F5（または Shift＋更新ボタン等）」を日常的に使って「確実にサーバー最新版を取得」するのが安心です。記事にも大まかに触れられています。
本番環境では、むしろキャッシュを上手に活用することでページ表示を高速化できますが、更新後に旧リソースが残って「見た目が変わらない」「古いCSS／JSが適用されている」というトラブルも起こりやすいです。
→ そこで「バージョニング（例：style.css?v=1.2.3）」や「ハッシュ付きファイル名（例：style.abc123.css）」などを併用すると、ユーザーにキャッシュクリアを意識させずとも確実に更新を反映させられます。
→ また、CDN（コンテンツ配信ネットワーク）を使っている場合、CDN側キャッシュのクリアやパージ（purge）が必要なケースもあります。
モバイル・タブレット・複数ブラウザでの挙動差
記事では主要なブラウザ（Chrome, Edge, Firefox, Safari, Opera）での「スーパーリロード」のキー操作をリストしています。ただし、モバイル環境（スマホ／タブレット）やブラウザ拡張機能、企業内のカスタムブラウザでは、キー操作が異なる／押してもキャッシュが残る／そもそも更新ボタンしか無いというケースもあります。
→ 例えば iOS の Safari では「更新ボタン長押し→再読み込み／キャッシュの消去」など特殊な操作になることがあります。
→ また、企業／学校環境でプロキシサーバーや内部キャッシュ（例：Squid／キャッシュサーバー）が間に入っていると、ブラウザ側で「Ctrl＋F5」しても完全に最新が来ないことがあります。こういった場合は、プロキシキャッシュクリアが必要／あるいはバージョニング戦略を必ず採るべきです。
リロード頻度とユーザー体験のバランス
頻繁に「Ctrl＋F5」を強制する設計（例：ボタンを押させる／ユーザーに再読み込みを案内する）をしてしまうと、ユーザー体験が損なわれる可能性があります。回線が遅い環境やモバイル回線では、「ページが一瞬消えて、再読み込みになった」印象を与えてしまうことも。
→ よって、可能であれば「差分更新」の設計（新旧CSS/JSの両方互換）や「ローディング中のUI／スピナー表示」でユーザーに待機時間を意識させない工夫も有効です。
→ また、キャッシュ切れをユーザーに知らせるインターフェイスは、必要以上に派手に表示しないことで「更新作業中なのかな…」という不安を軽減できます。
ブラウザ開発者ツールの活用
Web開発時、キー操作以外にも、ブラウザの開発者ツール（DevTools）を使って「キャッシュ無しで再読み込み」を行うことも可能です。例えば、Chrome では「デベロッパーツールを開いた状態で右クリック→再読み込み→キャッシュを無視してハード再読み込み」を選択できます。
→ これにより、ユーザー側のキー操作に頼らず「確実に最新リソースで表示をチェック」できます。
→ また、ネットワークタブで → Disable cache（キャッシュ無効化）をチェックしておくことで、開発中は毎回最新を取得させる設定にできます（ただし、タブを閉じると元に戻ります）。
結論としての注意点
結局、「F5」はキャッシュを使ってリロード、「Ctrl＋F5（または他のスーパーリロード操作）」はキャッシュを無視して最新を取得という違いがあります。しかし、現実には「キャッシュをどう制御しているか（ヘッダー／CDN／プロキシ）」「ユーザーの環境（モバイル／社内ネットワーク）」「開発運用の体制（バージョニング／キャッシュクリア運用）」という“周辺条件”が非常に重要です。これら全体を俯瞰して設計・運用することで、ユーザーにとって快適で信頼できる表示体験が実現できます。
junitでexceptionが発生した事の確認テストはどのようにすれば良いかメモしておきます。
exceptionの発生確認は@Test内に「(expected = [確認したいExceptionクラス])」を指定する事で簡単に確認する事が出来ます。
|
1 2 3 4 5 6 7 8 9 |
@Test(expected = IndexOutOfBoundsException.class) public void testIndexOutOfBoundsException() { // 準備 List<String> test = new ArrayList<String>(); test.add("abc"); // 実行 test.get(1); } |
ちょっとdjUnitで「addReturnValue」を使用しても全く効いてない？という事象に少しハマっていたので原因についてメモしておきます。
addReturnValueが効かない原因として上げられるのが概ね以下の3つになるかと思います。1と2については少し見なおせばすぐ発見出来そうですが、今回ハマった原因が3でした。。。
では「指定したメソッドが複数回実行されている」というのはどういう事かというとについて説明します。
根本的な話として以下の2つのコードは全く同じ意味という事を理解しておく必要があります。
|
1 2 |
addReturnValue(UtilClass1.class, "getStr", expected1); setReturnValueAt(UtilClass1.class, "getStr", 0, expected1); |
これだけで気づく方はハッと思うかもしれませんが、ここで重要なのはaddReturnValueでは「1回目に実行」されたメソッドのみしかaddReturnValueで指定した値が返ってこないという事です。つまり「setReturnValueAt」で1回目を指定した場合と同様の動きしかしてくれないのです。
今回私がハマったのは指定したメソッドが想定した箇所よりも手前で事前に実行されていた為、想定したいたメソッドは2回目の実行になっていたために2回目の方にはaddReturnValueが効いていなかったという事象でした。
addReturnValueをしてクラス名やメソッド名は正しいのにどうも効いていないように見える時は一度「getCallCount」でメソッドの実行回数を調査して見ると良いかもしれません。
djUnitではメソッドが呼び出されている事の確認は「assertCalled」を使用する事で確認出来ましたが、逆にメソッドを呼び出されていない事の確認では「assertNotCalled」を使用する事で確認出来ます。
|
1 2 3 4 5 6 7 8 9 |
/** * <p>[概 要] メソッド呼出サンプル確認用</p> * <p>[詳 細] </p> * <p>[備 考] </p> */ public static void sample1(){ String strEscape = htmlEscape("sample1-1"); String strEncode = urlEncode("sample1-2", "sample1-3"); } |
|
1 2 3 4 5 6 7 8 |
@Test public void testSample1_2() { // 実行 UtilSample1.sample1(); // 検証 assertNotCalled(UtilSample1.class, "getDiffDays"); } |
djUnitではassertCalledを使用する事でメソッドが呼び出された事が確認出来ます。
|
1 2 3 4 5 6 7 8 9 |
/** * <p>[概 要] メソッド呼出サンプル確認用</p> * <p>[詳 細] </p> * <p>[備 考] </p> */ public static void sample1(){ String strEscape = htmlEscape("sample1-1"); String strEncode = urlEncode("sample1-2", "sample1-3"); } |
|
1 2 3 4 5 6 7 8 9 |
@Test public void testSample1() { // 実行 UtilSample1.sample1(); // 検証 assertCalled(UtilSample1.class, "htmlEscape"); assertCalled(UtilSample1.class, "urlEncode"); } |
以下の様に「getCallCount」を使用する事でメソッドが何回呼び出されたかを確認する事も出来ます。
|
1 2 |
int countHtmlEscape = getCallCount(UtilSample1.class, "htmlEscape"); assertEquals(10, countHtmlEscape); |
djUnitでテストする際に、一部のメソッドは特に実行する必要はないけどそのメソッドの処理はスルーさせたいケースがたまに発生します。こういう場合にはdjUnitのaddReturnValue機能を活用する事でそのメソッドの処理を無効化する事が出来ます。
通常addReturnValueはメソッドの戻り値を好みの値に変更する際に使用しますが、戻り値なし（void）のメソッドの時には通常使用しません。それでも戻り値なしのメソッドをaddReturnValueで指定するとそのメソッドが実行されずメソッドの処理を無効化する事が出来ます。
ただし、この方法は戻り値なし（void）のメソッドにしか活用出来ませんのでご注意下さい。
|
1 2 3 4 5 6 7 8 9 |
/** * <p>[概 要] メソッド無効化サンプル確認用</p> * <p>[詳 細] </p> * <p>[備 考] </p> * @param String 文字列 */ public static void sample1(String str){ System.out.println(str); } |
|
1 2 3 4 5 6 7 8 |
@Test public void testSample1() { // 準備：メソッドの無効化 addReturnValue(UtilSample1.class, "sample1"); // 実行 UtilSample1.sample1("sample1メソッドが実行されました"); } |
djUnitでメソッドの返却値を好みのものに変更する場合は「addReturnValue」メソッドを使用しますが、
同一メソッドを複数回使用していてそれぞれ別々の戻り値に変更したい場合には「setReturnValueAt」メソッドを使用します。
|
1 2 3 4 5 6 7 8 9 10 11 |
public class UtilClass1{ /** * <p>[概 要] サンプルメソッド</p> * <p>[詳 細] </p> * <p>[備 考] </p> * @return 文字列 */ public static String getStr(){ return "hoge"; } } |
|
1 2 3 4 5 6 7 8 9 10 11 |
public class DriverClass1{ /** * <p>[概 要] ドライバーメソッド</p> * <p>[詳 細] </p> * <p>[備 考] </p> */ public static void driverMethod1(){ System.out.println(UtilClass1.getStr()); System.out.println(UtilClass1.getStr()); } } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
import jp.co.dgic.testing.framework.DJUnitTestCase; import org.junit.Test; public class UtilClassDjUnitTest extends DJUnitTestCase { @Test public void testGetStr2() { // 準備：getStrメソッドの返却値を1回目と2回目で別々の戻り値に変更します。 String expected1 = "test1"; String expected2 = "test2"; setReturnValueAt(UtilClass1.class, "getStr", 0, expected1); setReturnValueAt(UtilClass1.class, "getStr", 1, expected2); // 実行 DriverClass1.driverMethod1(); } } |
|
1 2 |
test1 test2 |
