実践中の再構築29_自動化されていないテスト

テストの真髄の一つは自動化です.すべての自動化可能なものを自動化し、貴重な人力を節約し、効率を極めて向上させる.
UnitTestの実装を見てみましょう

	@Test
	public void test() {
		Date start = DayUtil.parseDate("20110101");
		Date end = DayUtil.parseDate("20110110");

		Map<Date, DayOrderStat> result = orderQueryService.queryUserOrderStat(
				"normalUserId", start, end);
		result = orderQueryService
				.queryUserOrderStat("emptyUserId", start, end);
		result = orderQueryService.queryUserOrderStat("exceptionUserId", start,
				end);
		Assert.assertNotNull(result);
	}

UTはインタフェースの対応するUTコードです.元のインタフェースは次のとおりです.

public interface OrderQueryService {

	/**
	 *  。
	 * 
	 * <pre>
	 *  ：
	 * 1  ， Day,DayOrderStat 。
	 * 2  ， Day,null 。
	 * 3  ， 。
	 * </pre>
	 * */
	public Map<Date, DayOrderStat> queryUserOrderStat(String userId,
			Date start, Date end);
}

インタフェースに異常があることが判明すると、このUTがうっかり見えてしまいます.開発者はIDEを開き,ブレークポイントを加えて,このUTを単一ステップで実行し,どこで問題が発生したかを追跡する.
UTで完了するはずのタスクが手動で完了しているのを見て、明らかに、このUTはUTの役割を果たしていません.
このUTは一般的なUTの記述パターンと原則に合致せず、このUTが検証方法の実現を自動化できないかどうかを決定するとともに、問題が発生した場合、UTも迅速な位置決め問題の開発を助けることができない.
一般UTの作成パターン:
1 UTの実行環境を設定します.
2テストする方法を実行します.
3検証結果.
または契約に基づく作成パターン:
1 UTの実行環境を設定します.
2メソッド呼び出しの前条件が満たされていることを確認します.
3テストする方法を実行します.
4検証結果.
ここのUTはUTの基本原則、隔離性に違反しています.
1つの方法で複数の実行パスがある場合、異なる実行パスは異なるUTで検証できます.